Creating and Managing Temporary Work Objects in PEGA

Before We Begin

First let us understand what are temporary work objects in PEGA. As the name suggests, these are work objects which are not permanent, i.e. they are not stored in the Database. They just remain in memory [Clipboard] and do not have any case ID associated with them. They are created and managed by a single operator who has initiated the case and cannot be routed.

Why do we need Temporary Work Objects?

There may be situations where we need to store work objects in database only when certain conditions are met. We can make use of temporary work objects in these scenarios.

Few scenarios where Temporary Work Objects can be used:

• Consider that there is an insurance application where a customer can launch and get the quote. Based on the quote, customer might want to proceed or reject. We can use temporary work object to present the quote. Once customer approves, we can make it permanent. If the customer rejects, we need not store the details in the Database.
• Consider that in a reimbursement application there is a duplicate check to handle if the reimbursement claim is duplicate. In this scenario, we can initially create a temporary work object, perform duplicate search and then make it permanent only if it is a non-duplicate case.

Note: If system requires storing each and every case [irrespective of Resolved-Duplicate/Resolved-Rejected] for audit purpose or for future analysis, then temporary work object might not suffice.

Business Scenario

Let us extend our Candidate Onboarding process which we used in our previous Duplicate search post .

Our requirement is that we only need to store non-duplicate candidate profiles in our Database and do not need to store those cases that are identified as Duplicates.

We can implement this scenario using Temporary Objects and use Persist Case shape to store non-duplicate cases. Let us see this implementation in detail.

How to create Temporary Work objects in PEGA?

PEGA Case Management provides us with an option of creating temporary work objects. Using Case Design, follow below navigation to create temporary work objects.

Case Type (Candidate Onboarding in our scenario) -> Settings tab -> General category -> “Enable temporary case”

Enabling this will make the Candidate Onboarding case a temporary until we choose to make it permanent by using Persist Case shape.

Once this option is enabled and Saved, we can notice that the starter flow pyStartCase in Candidate Onboarding class has the settings for Temporary Object enabled.

How to make a temporary work object permanent?

We can use the Persist Case option in case management to make a temporary case permanent whenever it is desired to be persisted.

In our scenario of Candidate Onboarding, we intend to persist a case only when it is not a duplicate case. After the Duplicate Search step, we add Persist Case step so that only the non-duplicate cases are stored in the Database.

Execution of Temporary Work object

With the above changes, let us try to create a new Candidate Onboarding case. Here we can see that a case ID is not generated for the case when we are in the step of collecting candidate details.

Let us open the clipboard and observe work page and assignment page.

Let us fill the candidate details for a Candidate whose record doesn’t exist in the system. Duplicate Search determines this case as a non-duplicate. After this, case passes through Persist Case shape which will make the case as permanent. Case ID is generated and the case gets stored in the Database.

Let us create another Candidate Onboarding case with same details as the case which we had just created.

Let us close this case as Duplicate and Submit.

We can see that the case has got resolved as Duplicate and the case details are not persisted in the Database.

What is happening in the backend?🤔

To createWorkPage activity, parameter value for CreatesTemporaryObject is passed as true from pyStartCase flow settings. Due to this pyTemporaryObject property in work page is set to true.

Generation of work object ID is skipped in AddWork activity if pyTemporaryObject is true. Hence, work object ID is not generated when temporary object is enabled for a case type.

RecalculateAndSave activity exits when pyTemporaryObject is true.

At the backend, whenever case passes through Persist Case shape, pxPersistCase activity runs.

This activity does the following:

• Removes pyTemporaryWorkObject property.
• Gets the work object prefix and calls GenerateID to generate the work object ID.
• Updates work object reference properties in newAssignPage [pxRefObjectKey etc.]

Overall SLA

Let us set an overall SLA for the Candidate Onboarding case type and examine what happens when the case is temporary and after it becomes permanent.

Let us run the Candidate Onboarding case and observe what happens when the case is not persisted.

Let us observe what happens when the case crosses Persist Case shape and becomes permanent.

We can notice that pxPersistCase calls pzLaunchInternalFlows which calls DefineSLATimes and after which OverallSLA gets set on the case.

We can also notice that other Internal flows becomes available in pxFlow pagegroup when pxLaunchInternalFlows gets called from pxPersistCase.

Conclusion

Temporary work objects can help improve storage space as it eliminates unnecessary DB storage by not storing the case data which are not needed. It also helps improve performance.