In the portion of this help document that discusses the field "Source Page Parameter Name", this is the entirety of the help text:
Source page parameter name
Appears if you select Create multiple cases."
I'm not really sure what to say here. What is missing?
- Description of what is needed in this field. Or if it is optional/required, what are the ramifications of not providing this?
- Usage - what is the meaning of this field?
- Example of how to use this
Just telling a user that this field appears - without instruction of how to use it - does not really qualify as helpful, in my opinion. Is the expectation that the parent / covering case name is to be put here? What is this field used for?
In Pega 7.1.10, the Help topic you reported, the info block Source page parameter name, will include a link to the new topic that was added for Pega 7.1.8, Case Management, Case Designer, Steps, Case Steps, Creating multiple child cases
In the search area, once you do a search, there is a "Forums only" checkbox. It would be nice to have the reverse of that - "Exclude Forums". This would help filter out some of the 2006-era questions that are still in the Forums and have no relevance to me...
Yes, Jim. That's how filtering works -- by creating subsets of found content based on the metadata of the search index.
By filtering your search results, you are restricting/sub-setting the content found by general search on your keywords.
In your example, you can find PRPC 7.x content for the keywords you specified in all of the displayed content types, topics (categories), and forums -- as seen in your screenshot.
Once you start narrowing the the PRPC 7.x filter by adding other filters, your search results -- and the additional filters available to you -- become restricted.You have fewer choices because the found content is not available in those other filter categories.
And Ben's work-around for Exclude Forums is correct.
I recently submitted the following issues to the PDN team (using PDN Contact Us -- link available to all PDN users in the footer of every PDN page).
PDN SERP usability issues
The link Search Query Syntax (a Help topic) might be better positioned at the top of the SERP. It's currently hidden at the bottom, where new users are unlikely to see it.
A filter for Exclude Forums (counterpart of Forums Only) would be great to have. Yes, I know that the other filters implicitly cover the Exclude Forums need. But having Exclude Forums as a top-level, general filter would be loved by many users.
Show Filters currently supports one-at-a-time incremental addition of filters. User has to reselect Show Filters each time to add a filter. Multiple-select of filter check boxes -- without the SERP refreshing after each selection -- would be great to have.
I was searching for information on filling out the send-email smartshape, with regards to how to include things like the Case ID, etc.
When I get to this link, it says
Required. Enter a text string or a property reference.
Click the appropriate radio button to create your message with the Rich Text Editor or a Correspondence template.
It would be nice to have some sort of example or syntax to how to include a property reference such as Case ID or some other value off of the case.
I can't seem to find that anywhere, and if you can show an example here (or provide a link to another help screen that has it) that would be much more helpful. From the help given here, I don't know anymore than I did when I came in.
The issue is, nowhere in the help text does it explain HOW to get to the screen where you enter the Tab Skin. Which is done by doing the rather non-intuitive "Click the down-arrow next to Dynamic Layouts, then choose Tab from the popup window" as shown below:
I realize screen shots can't be added because of last minute UI changes, but can we at least have an explanation of the navigation? Currently the help says we CAN edit Tab skins, but not how to get to the screen.
The General tab for properties has three sections: Property Type, Data Access, and Display and Validation. See below for information about each section.
Great! Now, search for "Display and Validation" in this topic. There is no further mention of this anywhere in this topic, and going on the to the next topic ("Advanced"), it's not there either. Where can I find details about Display and Validation for Data Model properties?
I am trying to find some sort of listing or report of a data dictionary of the -Data classes in my application. In the help, I can use the Index to find data dictionary, and within that, is a link called "listing". The link goes to the help topic link which i posted above, and the resulting page has zero references of "dictionary" and/or "listing".
Is this just a bad link, or what connection is there between the resulting page and the inquiry?
If that answers your question, would you please mark your post above as Correct Answer? Thanks!
(When using a new tool, I often find that taking some relaxing time -- not doing work, not performing a task -- to simply cruise around the UI helps me get oriented to what's there and what's where. This is similar to reading a book's Table of Contents and its Index. <Read/scan an Index?!? Yep, some of us crazy writer-types actually do that.>)
Perfect way to mark the reply. After discussing with Mary, we decided to unmark this thread as a question since it was more of an open ended discussion that doesn't have any one correct answer per se. In doing so, the option to mark a reply as correct answer went away.
So marking it as a decision is a great way to handle this. Thanks for setting the precedent.
Below is the "Data Pages" help screenshot for PEGA 7.1.6 and I think it will be really beneficial to list out the all rule names, which can refer the data pages instead of saying "Many rule types"....Thanks
Thanks. By "PDN GCS form" I meant SR's. But, true, I don't like SR's due to their closed nature.
My basic tenet from years of BPM is that any request is a first-class object, and ought to have a form on its own. So wherever that can be supplied, would be great. Tacking on these to a single thread is problematic, since, invariably, each request might spawn its own conversation (e.g., Designer Studios menu evolution in v7.1.7 ), which should be managed independently of the others.