Locking config for Case Type?
The locking configuration in the Case Designer and the locking configuration here in the advanced tab of the case type rule are different. Case Designer locking configuration is valid for cases that are instantiated under a case hierarchy. The locking configuration here is valid for cases that are instantiated as stand-alone case instances.
pxIsInCurrentStage
When a specific step of a stage is processed, subsequent step in that stage will be automatically kicked off, if that is marked to start “upon completion or skip or previous step.” In the previous step, if we change to a previous stage using the “Change Stage” smart shape, another step in the previous stage also started. If this effect of two steps across two stages getting kicked off is not desired, we can have the standard when rule “pxIsInCurrentStage” in the subsequent step.
pzApprovalFlowWrapper
Step Type:
Approval — creates a flow rule with a single subprocess shape. The subprocess shape calls the standard pzApprovalFlowWrapper flow. Approval steps can be configured for processing by a single operator, or a cascading series of operators based upon either the existing reporting structure or an authority matrix configured by a decision table. The cascading approval option behaves similarly to the Cascading Approval smart shape, and can be configured in the same manner.
Subcase instantioation options
The different instantiation options are:
• Subcase Case Designer
• Step Configuration in the Parent Case Designer
• Create Case Smart Shape in any Flow rule
Locking and Timeout in Case-Subcase relationship?
Remember if the parent case has default or optimistic locking and the subcase is instantiated under the parent case hierarchy, then the subcase also has default or optimistic locking respectively. But, we can change the custom timeout for the subcase, irrespective of the timeout settings in the parent case, for default locking configuration.
Cascade approval can be based on?
What is set on the start shape of a screen flow?
Routing, like harness, persistence and error handling,
What configuration is missing from an assignment in a screen flow?
ticket, SLA, notify
How work status update is happening?
standard activity Work-.UpdateStatus updates Work-.pyStatusWork.
Also calls Work-.UpdateStatus:
Activities such as Work-.WorkBasket and Work-.Worklist which place an assignment in a workbasket or worklist respectively, also call Work-UpdateStatus.
Standard functionalities levereging Work Status
When a case instance/work item status is first updated to a “Resolved” status, PRPC calls the Resolve activity automatically. This activity activates the “Status-Resolved” ticket. Another particular standard ticket is “AllCoveredResolved.” If a subcase status becomes Resolved, the immediate parent case is checked. These standard tickets are covered in the “Tickets” lesson.
PRPC also automatically maintains three standard properties in Work-class. They are pyElapsedStatusNew, pyElapsedStatusOpen and pyElapsedStatusPending. These properties contain cumulative time in seconds that a case instance has had a status value that started with the word “New”, “Open” or “Pending” respectively.
Work Party setup fields on case type rule?
Available Work-Party types?
Party/Company, Party/Government, Party/Operator, Party/Non-profit, Party/Perso
Special ways to provide adding work party function.
we can either include the “Work- • pyWorkPartiesWrapper” section rule wherever we want or we can use the “AddParty” flow action as local action at the assignment level,the flow level, the stage level or the case level. Below is the configuration at the assignment level local action.
Normal ways:
configuration in the Case Designer, or by using the standard perform harness, new harness
List vs Group
One important decision we have to make is choosing between the group or list concept. Lists are particularly good when we always want to display or process all of the items in a list. Their subscripts do not carry much context as they are just numbers. However, when displayed they are guaranteed to show up in the same order. On the other hand, groups have string subscripts which can add context to each page, making direct lookups easier. However, when looping over a page group the order in which the group is traversed is not always consistent since it is built on top of a hash table. When deciding between page group or page list, consider if you will be working on a specific item in the collection, in which case a group is helpful, versus all items in the collection, in which case a list may be more appropriate.
On which UI elements can responsiveness be set?
Conditions is evaluated on the client if?
In which order are rules and data instances applied for a connector?
In which order are rules and data instances applied for a service?
In which class would you expect to find the SOAP connector rules? (based on the selected reuse option)
Implementation: Org-App-Int-Supplier
Organization: Org-Int-Supplier
Global: Int-Supplier