assignment shape in pega

Wait Shape – its Configuration, Usage & Execution

This article discusses about Wait shape, its configuration, usage and execution.

Before We Begin

From OSP dictionary, we would define Wait as a mechanism to pause/halt the execution of the flow for a specified time/ specific event and to resume it when the wait time/event has occurred.

Consider an online bus ticket booking application where the system should send a feedback form to customers after a day of travel. The task of sending feedback form to the customer can be achieved by configuring a wait shape with a time interval of 1 day.

The above requirement can also be achieved using the Service Level Agreement in PEGA. But the key considerations of using wait shape are listed below,

• The task to perform does not have any Goal, Deadline or Passed Deadline events.
• The task to perform does not require updating case urgency/priority. It’s all about sending a feedback form email to customers.

What is Wait shape?

Wait is a smart shape available in flow rule. As the name implies, wait shape is used to instruct the system to wait for a specified time period or for a specified business event to occur before allowing the case to advance.

How to configure a Wait Shape?

• Open the flow rule where you want to include the wait logic and add wait shape from the list of smart shapes available.

• Timer – We can make the case wait for a specified time period (in days, hrs, mins, yrs, months, weeks).
• Timer – We can make the case to wait for specified date-time defined using a property.
• Case Dependency – We can make the case to wait for one or more cases of a specific case type to get resolved.
• Case Dependency – We can make the case to wait for one or more cases of a specific case type to reach a particular case status.

Wait type as Timer

If the time interval to wait is known ahead of time, then wait can be implemented using the timer. One example could be our online bus ticket booking application discussed above where the feedback form will be sent 1 day from the date of travel. Since the system should wait for a known interval of time [1 day], this can be implemented using timer. Timer in wait can be configured in two ways,

Date/time interval

Date/time reference.

• This makes the case wait for a specified time period (in days, hrs, mins, yrs, months, weeks).
• We can use this wait type when the interval to wait is static.

• This makes the case wait for specified date-time defined using a property.
• When the wait interval is referenced using property, extra caution is required to make sure that the property has value prior to referring it in wait shape.
• We can use this wait type when the interval to wait is dynamic.

Wait type as Case Dependency

Apart from the time interval, we can also configure the system to wait for a specific business event to happen before resuming the process.

Possible business events could be resuming the current case based on the status updates on other cases or resuming the current case when other cases are resolved.

Case Dependency – to be Resolved

• This type of wait makes the case to wait for one or more cases of a specific case type to get resolved.

• Selecting All as dependency type makes the case to wait for all cases created for a mentioned case type to be resolved whereas selecting Any as dependency type makes the case to wait until one of the cases of mentioned case type gets resolved.
• Any & All makes difference only when the number of dependent cases is greater than 1 .

Case Dependency – to reach Status

• This type of wait makes the case to wait for one or more cases of a specific case type to reach a particular case status.

• Selecting All as dependency type makes the case to wait for all cases created for a mentioned case type reaches particular status whereas selecting Any as dependency type makes the case to wait until one of the cases of mentioned case type reaches particular status.

Case Dependency – Scope

Scope is an additional attribute in wait shape when the wait type is configured as Case Dependency. Scope can be decided using three different options as shown below

• Current case
• Parent case

Before understanding the scope, let’s understand case hierarchy and its reference in PEGA.

The above sample explains what a Top, Parent and Current case in PEGA refers to. Now coming back to our scope in wait, the value specified in the scope determines from which level the dependent case should be considered.

Case Dependency – Scope – Current Case

• Child case of the current case

For instance: If the dependent case exists as a Parent case of the current case and if the scope is selected as Current Case, then the parent case will not be considered by the wait.

Case Dependency – Scope – Parent Case

• Parent case of the current case
• Current case [Sibling of the current case]

For instance: For a second-level child case, if the dependent case exists as a Top case and if the scope is selected as Parent Case, then the Top case will not be considered by the wait.

Case Dependency – Scope – Top Case

When the scope is defined as a Top case in case dependency, then the system considers the cases of the dependent case type from any level it exists.

• Top case of the current case

Users can choose to continue process

• Enable this to allow users (who have access to the wait workbasket) to resume the process manually. Users can manually perform the wait assignment only when this option is enabled.

Local action permitted for end-user :

• We can configure the list of other actions that users [ who have access to the wait workbasket ] can perform when the case is in wait.
• With the above configuration shown in the screen-shot, the user can launch a local action to add work party when the case is in wait work-basket.

Advanced wait options:

System allows us to configure additional options under the advanced section of wait shape.

• Assigned To Workbasket : PEGA defaults to [email protected] Workbasket. This can be changed if required.  The case will wait in this workbasket until the specified conditions are met.
• Harness Name: Harness that will be used when a case is opened manually from wait workbasket.
• Instructions: This acts as the assignment label when the wait case is opened manually in Review harness.
• Service Level: Wait shape can have a SLA, which can define goal, deadline and passed deadline events of wait assignment.

Hope now the steps to configure wait shape is clear. Let’s quickly implement few scenarios using wait shape to see its usage and back-end execution.

Business Scenario

Let’s consider the same onboarding application scenario that we used in our Service Level Agreement post .

• An onboarding case will be created for each candidate and invitation email will be sent to the candidate with a link to upload documents.
• The candidate should upload all the required documents using the link provided in the invitation email.
• Once uploaded, system creates a separate child case to perform background verification.
• If the verification is successful, the onboarding case resumes its process, else the system creates an exception case and notifies Candidate and HR.

Case life cycle

Case Structure

Scenario 1 – Timer

Each candidate will provide their preferred date-time to get started with the on-boarding process. Hence the system should create the case and wait till the preferred date-time before sending the invitation link.

Implementation

• This will be implemented using wait shape with wait type as a timer. Since the interval is dynamic, wait type should be configured to use date-time reference.

• Preferred date-time can be collected from the candidate during the onboarding case creation.

• System creates a workbasket assignment and case waits till the entered date-time is reached. Users can perform the wait assignment manually since the option to perform is enabled in the wait configuration.

• When the mentioned date-time is reached, system resumes the onboarding case and sends an invitation email to the candidate.

What happens at the back-end? 🧐

When the case reaches wait shape configured in the flow,

• System creates an assignment entry in the pc_assign_workbasket table using WorkBasket activity.

• System writes an entry into the queue table System-Queue-ServiceLevel using AddAssign activity. The date-time value of the property AvailableDateTime will be set to pyMinimumDateTimeForProcessing which will be used to execute and resume the case.

• Entry written into the queue table will be processed by the agent PEGA-ProCom: ServiceLevelEvents . The same agent that processes SLA events will be used to process wait entries from the queue table.
• Once pyMinimumDateTimeForProcessing in queue entry is reached, the SLA agent processes the entry and resumes the flow using pyContinueAfterWait flow action. Pega by default refers the flow action pyContinueAfterWait in wait’s shape outgoing connector

Scenario 2 – Case Dependency

Once the documents are successfully uploaded by the candidate, the system creates a background verification child case that verifies the uploaded docs. The onboarding case should wait until the completion of the background verification case and should resume once it is resolved.

• This will be implemented using wait shape with wait type as Case Dependency. Since onboarding case should resume when verification case is resolved, wait is configured with case dependency as shown below,

• Once the document upload process is completed, system creates a workbasket assignment and the onboarding case waits until the created verification case is resolved.

• When the verification case gets resolved, the onboarding case resumes its process.

When the case reaches wait shape with case dependency configured in the flow,

• OOTB activity Dependency gets invoked which in-turn calls WorkBasket activity to create an assignment entry in the pc_assign_workbasket table.

• When the Assignment page gets saved, an OOTB Declare index rule pxAssignmentDeps is called and it saves all the Assignment Dependency properties in an Index table PR_INDEX_ASSIGNMENTDEPS .
• Entries will be written into the index table for workbasket assignments only if the when rule pzHasDependencyProperties mentioned in the declare index rule evaluates to true.

• pyDependencyClass : The case type class for which the current case is waiting for.
• pyDependencyStatus : The status of the case for which the current case is waiting for. The value is Resolved-% if the Resolved option is chosen in wait shape configuration.
• pyDependencyScope : Scope that is defined in wait shape configuration.
• pyDependencyAncestorClass : Class name of the parent case.
• pyWaitForAllCases : Sets to true if ALL is chosen in wait shape configuration.
• pyActionName : pyContinueAfterWait, the flow action to resume after the wait.
• Declare trigger pyCaseDependency gets created for each case type when tagged as a dependent case type in wait shape. In our scenario, the verification case type is configured as a dependent case type for onboarding and hence declare trigger pyCaseDependency gets created in verification work class.

• When the verification case is resolved, declare trigger pyCaseDependency gets invoked and the trigger activity pxCheckFlowDependencies queries the PR_INDEX_ASSIGNMENTDEPS index table and resumes the current case based on the result.

Pointers to remember

• Wait shape can be used when there is a need to pause the case for some time or to wait for a case to reach a status.
• Wait shape can be used instead of SLA when the business logic is just to execute an action with a system pause [No prioritization and no escalations].
• When the case is dependent on more than one case type, then wait shape can be used in conjunction with the AllCoveredResolved ticket. This will be elaborated in our future posts “ Tickets in PEGA “.

OSP Editorial Team

We are a team of 3 CLSA’s who strongly believe in the fact that Learning is nothing without sharing.

OneStopPega is purely out of our love and passion for PEGA.

Recent Jobs from our community

Join the discussion cancel reply.

Feel free to post your questions here about this topic if any. We will definitely get back to you ASAP !!! If you have any off-topic questions, Let's discuss at OSP Forum

Save my name, email, and website in this browser for the next time I comment.

Enable this to get email notification when someone respond back to your comment

Enable this to Subscribe for instant email notification on new article

24 comments

Phew too much of information to digest. Not able to follow at all, got lost in the mid way. Please kindly split and explain things instead of providing too too too much information as 1 veryyy lengthy article.

Thanks for your comment @Nishant M Rangekutta We planned well before writing this post to organize content without overloading it, but somehow we are not sure why you feel it that way. We will try to incorporate your comments in upcoming posts.

Feel free to contact us if you have difficulty in understanding our posts. We will feel happy to help you anytime 🙂

Happy learning from OSP 😊

Excellent…

Thanks @Upender Reddy

Happy Learning from OSP😊

One question-what if there are many levels -more that 3 levels,say 5 levels in case hierarchy -then if scope is made as TOP then will it only consider the topmost parent case as dependent? how to configure wait shape at child case to wait for the 4th Parent case to resolve/attain as specific status?

Having scope as TOP will ensure that the dependent case is considered all the way starting from highest in the level to the lowest in the level.

Let’s consider few examples in 5 level case hierarchy to understand this clear, 1) If we want level 3 cases in hierarchy to resolve when level 4 case in the hierarchy is resolved, then wait shape can be configured in level 3 case with scope as current case and dependent case type as level 4 case type [level 4 cases are child case for level 3].

2) If we want level 4 cases in hierarchy to resolve when level 3 case in the hierarchy is resolved, then wait shape can be configured in level 4 case with scope as Parent case and dependent case type as level 3 case type[Level 3 cases are parent case for level 4].

I have a parent case and two child cases. I want parent case to wait until an assignment “ABC” is completed in child case 1 AND assignment “XYZ” is completed in child case 2. Please note both the sub cases are active after the assignment completion.

I think ticket can be raised at the end of an assignment completion from child case after checking the assignment status of the sibling case. Earlier, there was a pyWaitForCase flow to handle mid process dependencies. It does not seem to be there in infinity. Any thoughts?

Where can i get link for article “Tickets in PEGA“ mentioned in above post?

When the case is dependent on more than one case type, then wait shape can be used in conjunction with the AllCoveredResolved ticket. This will be elaborated in our future posts “Tickets in PEGA“.

Thank you for asking that. It’s there in our queue. You can see it soon on our site.

Guys 1 basic question. I have a case design A which creates 5 child cases B. I want to resume A after 5 Bs are resolved. Will A get automatically resolved when all 5 Bs are resolved? If yes, how to handle. Once Bs are resolved, from A I need to do further processing.

If 5 child cases are of the same case type, then it’s configurable in wait shape. This configuration will create a declare trigger at the back-end which ensures Case A is resumed once all open Cases of B are resolved.

Will case A also be resolved? That is my doubt or should I customised all tickets resolved and all?

If you just want to resume Case A, then ticket configuration is not required. When all the configured child cases are resolved, the system automatically resumes the flow in Case A.

Achacha. Ok, Aditya also said so. But I wanted expert opinions like u. Thanks for quick reply

There is no one called as an expert. It’s just persons with different areas of expertise.

No one knows everything, but everyone knows something!!!

Happy Learning from OSP 😊

One question again around the same lines. Will child resolution raise allcoveredresolved ticket and close parent also? I want A to resume after all Bs are resolved.

Resolve API which gets invoked whenever a case gets resolved takes care of this logic.

Whenever a child case gets resolved, the system verifies if any of the child cases are open for the current parent. If Yes , it waits for the other child cases to be resolved. If No , system sets the ticket AllCoveredResolved .

Hi Team, a very informative post as always. You guys are doing really great 🙂 Keep doing this and keep ignoring some unwanted comments 😉

A few queries: 1) Is it mandatory to use the pyContinueAfterWait flow action for every wait shape or I can give my own custom?

2) Will the case dependency not solve the below scenario:

Case Type A – Parent Has 2 child cases B and C.

Now I should configure A to wait till all child cases (B and C) are resolved? Will, this not work with the ‘All’ option? Is this the one that you have mentioned in last saying it has to be in conjunction with tickets? If yes then can you please let me know in brief how this can be achieved?

Thank you so much and we do listen to negative comments if it’s valid 🙂

1) We can use any flow action to resume the wait shape. The flow action name to resume will be set in the queue entry and Pega uses that to resume the flow when the wait time is reached. We just need to make sure we don’t have any validation rule or any post-activity that might potentially fail as part of the flow action being used.

2) Wait shape can be used to wait at a time for only one case type. ANY & ALL option applies to the number of cases under one case type. Whether to wait till all the cases of the mentioned case type is resolved or any one should be resolved. When we want to wait for multiple cases of different child case types, then we should use AllCovereResolved ticket to achieve that. Pega invokes this ticket when Resolve activity is invoked from child cases. If the number of child cases open becomes zero, then this ticket will be fired which will resume the parent case.

Guys ,Nailed it with your explanation. Take a Bow. your article helped me to explore OOTB functionalities. Thanks a ton.

Thanks much, Aravind

Hi Team, Thank you for the explanation, I have below query.

Child Case B goes through below status values: Pending-Delivery Pending-Payment Resolved-Completed

Parent Case A: Once all the deliveries are complete, there is a action, e.g. send notification to one of the party . We can configure a wait shape with wait type as ‘Case dependency’, wait for ‘All’ child cases to reach status ‘Pending-Payment’ and scope as ‘Current case’.

Scenario: Child case B1 – Pending-Delivery Child case B2 – Pending-Payment Child case B3 – Resolved-Completed (Resolved after delivery and payment are complete, i.e., case went through status Pending-Payment)

When B1 completes the delivery it will reach status ‘Pending-Payment’. Now at this point, will the wait shape configured in parent case work correctly? The target status reached for all the child cases but current status of all child cases are not same.

Thank you for the great explanation! What is the Scope “Other” used for? Hope we can use any case type which is not in case hierarchy (and not having Parent child relationship). Could you please elaborate more like how system will establish relation to other case types (sibling case) and any example if possible.

Very weel explained. Thank you so much

Further reading

Tickets in PEGA – its Configuration, Usage & Execution

Queue Processor – its Configuration, Usage & Execution

Job Scheduler – its Configuration, Usage & Execution