Wait Shape – its Configuration, Usage & 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.

• Wait logic can be configured using more than one ways as listed below,
  
  • 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

Date/time interval

• 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.

Date/time reference

• 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.
• Any & All makes difference only when the number of dependent cases is greater than 1 .

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
• Top 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

• When the scope is defined as Current case in case dependency, then the system considers the cases of the dependent case type from the below levels
  • 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

• When the scope is defined as a Parent case in case dependency, then the system considers the cases of the dependent case type from the below levels.
  • Parent case of the current case
  • Current case [Sibling of the current case]
  • Child case 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
• Parent case of the current case
• Current case [Sibling of the current case]
• Child 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 deferred@pega.com 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.

Implementation

• 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.

What happens at the back-end? 🧐

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.

• Few Key properties in the index table are,
  • 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“.