Tickets in PEGA – its Configuration, Usage & Execution

Before getting into the actual discussion. let’s see what is a go-to statement in programming language to understand the basics of tickets.

What is a go-to statement?

In any business process, flow might not always take a defined path. Exceptions are common in any business scenario in the given process.

For example, consider an online food delivery application Swiggy, where a typical business process is,

But it’s not assured that the process would always travel through the defined path. A customer who is about to complete the payment decides to add one (or) more item to the list. Now the customer should travel back to selection process from the payment process.

Programming languages supports functionality like go-to, labels, etc. to transfer the control of the program to the specified step anytime in-between the process.

Similar to go-to statement, Pega comes up with an OOTB rule called Ticket which can be used to jump between the process in a case.

Now let’s get into the actual discussion 📝

What is Ticket in Pega?

• Tickets are rule instances of class Rule-Obj-Ticket.
• A ticket (available under Process Category) can be used to jump to or go to another part (either backward or forward) of the current sequence of execution
• Tickets do not have any processing logic.

Why do we need Ticket?

In a flow processing, case usually flows through a pre-defined sequence of events. However, there may be certain exceptional scenarios where we need to leave the regular sequence of event and process an exceptional sequence.

Tickets are used to process out-of-sequence events. Tickets are entry point to a flow to handle any errors or exceptions or events defined by the user.

Business Scenario

Let us assume that OSP has a loan processing application and the sequence of events is as below:

• Client applies for a loan by submitting appropriate documents
• Loan officer reviews the documents and approves or rejects the request
• If loan officer approves, site visit is planned. If rejected, case will be resolved as Resolved-Rejected.
• Once loan officer visits the site, he can either approve, reject or select review.
  • When approved, loan process gets completed and case is Resolved-Completed.
  • When rejected, case will be resolved as Resolved-Rejected.
  • On selecting review, loan officer gets an option to revisit the documents and plan for site visit after revisiting the documents.

There are many ways with which we can handle these conditional events. In this post, we will be using Tickets to handle the conditional events.

How to configure Ticket?

Let us take the simple business use case defined above to understand more about tickets configuration and usage.

Let us first have the quick view of the case design to accomplish the above business requirement.

Stage 1 Initialize collects client information on loan requirements followed by appropriate documents.

Stage 2 Review is a stage where Loan Officer decides to approve or reject the loan case. Reject option should resolve the case as Resolved-Rejected. On approve, case is moved to an assignment where one of the three options – Approve, Reject or Review can be selected.

Now that we have the basic case design, let us create Tickets which we will be using in our scenario.

For the given scenario, how many tickets do we need to create?💭

We need 2 tickets to be created –

• Ticket to take the case processing to Resolved-Rejected in the events of Rejection during document review or site visit
• Ticket to take the case processing to Review when decision of review is taken while site visit step.

Let us create these two tickets now.

Go to Records> Process> Tickets> Create New.

Ticket rule form does not have any logic for processing.

Next step is to raise the tickets we have created. Let us see how we can do this.

Pega platform provides an activity method Obj-Set-Tickets using which we can raise a ticket. There is also an OOTB activity called SetTicket which can be called to set the ticket.

Let us take the 1^st scenario of Reject. If Loan officer decides to Reject the loan after document verification, the case needs to be resolved as Resolved-Rejected. Let us go to the Review stage and make this change to invoke a ticket in case of Reject.

Let us add a fork shape and configure the condition to continue the case if Approved and move to else path if Rejected. Now, invoke SetTicket activity to raise Reject ticket as shown below. SetTicket activity will take the Ticket Name as the input parameter.

We can see that SetTicket activity internally calls Obj-Set-Tickets method which accepts ticket parameter. Obj-Set-Tickets method can be used to SetTicket or Remove Ticket. SetTicket first calls Obj-Set-Tickets method by passing the ticket parameter as part of Set and re-invokes Obj-Set-Tickets method again by passing ticket parameter as part of Remove.

We have raised the ticket with SetTicket utility call. This needs to take the flow to Resolved-Rejected. Let us now implement this part so that when the ticket gets raised, case moves to Resolved-Rejected.

In Review_Flow, let us invoke a utility to Update the status as Resolved-Rejected and plug in the ticket so that when the ticket is raised during Review flow on rejection, the case control jumps to Resolved-Rejected path.

Most of the flow shapes like Assignment, Utility, End etc. allow to configure tickets. If a ticket is configured in a shape, it is indicated by a triangle with Ticket Name.

Let us run and check our implementation. We are creating a Loan Processing case and moving it to Document Review screen where Loan Officer rejects the case.

Let us trace and click on Submit. We can observe that SetTicket gets called which in turn calls OOTB activity FlowTicketEvaluate and raises Reject ticket. After this, case gets processed in UpdateStatus path and sets the case status as Resolved-Rejected, the case gets resolved.

We can use tickets to move the flow control backwards as well. Let us evaluate this by implementing the scenario where Loan Officer decides to move the case to Review during site visit.

Let us place the Review ticket in Review_Flow so that flow jumps back to the assignment to re-verify documents in case the Loan Officer decides to move the case to Review as part of site visit.

We can validate that the case moves to Review when we select Review as part of site visit.

One important thing to note in Ticket execution is, whenever a ticket is set, case can only navigate back or forth to the flow which is currently present in pxFlow page group.

When we were in Site Visit step (Closure_Flow), pxFlow page group had the following pages:

It was possible to move to Review_Flow from Closure_Flow as pxFlow had Review_Flow. If we had set the Review ticket on Collect Loan Info as part of Initialize flow, do you think it would have worked? 🙄

The answer is No. Since, Initialize flow has already completed, pxFlow will not have a page group for Initialize. We will not be able to move to the flow that has got completed or any flow that is not present as part of current pxFlow page group.

Have you ever wondered why Tickets and pxFlow are tightly coupled? 🤔

During our tracer review, we saw that OOTB activity FlowTicketEvaluate gets called when SetTicket gets executed.

OOTB Tickets

Pega platform also internally uses tickets in many scenarios. Let us look at an example which we most often use in application.

Parent case to resume processing after all child cases are resolved

Let us consider a Candidate Onboarding application which has a parent case for Onboarding and initiates two different child cases parallelly at the same time Beneficiary Enrollment and Stock Plan Enrollment. An onboarding case needs to wait until both the child cases completes.

If it was 2 child cases of same type, we can use a Wait shape in Onboarding with Case Dependency that all child cases are resolved for the parent to continue. In this scenario, it is 2 different child cases. How can we achieve this?

The solution to this is OOTB ticket AllCoveredResolved.

We can use Wait shape (with a sufficiently longer time within which both the child cases will complete) in the Onboarding case to make the parent wait and add AllCoveredResolved ticket to the flow shape after Wait.

As part of OOTB Resolve activity, whenever child case gets resolved, pyWorkCover is checked to see if there are any open child cases. When the last child case gets resolved, the value of pxCoveredCountOpen will become 0. When this condition is satisfied, AllCoveredResolved ticket is set as part of Resolve activity.

So, when the last child case gets resolved, AllCoveredResolved will get set and the parent case can continue further.

Use of Tickets in In-flight case processing

Tickets can also be used to handle in-flight cases. Let us say we have an application in Production with an assignment to Update Home Address and there are one or more cases in Production that are waiting in this assignment. However, there is a new change that instead of Updating Home Address assignment, we need to replace it with a screen flow that can update other details as well.

In case we decide to replace the assignment directly with the screen flow, we can use Tickets to handle the impact to in-flight cases that are waiting in the assignment which is no longer valid.

• Create a ticket and set it to the flow which had Update Home Address assignment.
• Write one-time activity
  • Fetch all the cases in Update Home Address assignment
    • Open and acquire lock on the impacted cases
    • Set ticket to move them to the starting of the flow.

Move the flow change along with this one-time activity change. Run the one-time activity so that all the impacted in-flight cases are moved automatically to the screen flow assignment.

Tickets vs Change Stage

There may be questions arising on when do we need to use Change Stage and when do we need to use Tickets.

To keep it simple, to jump between the processes, ticket can be used and to jump between the stages, change stage can be used.

Let us go through few scenarios to clearly understand the difference.

Scenario 1: Let us say there is a business requirement to enhance our case type with an optional action Reinitiate available during the Review stage. On submit of Reinitiate, the case should be go back to the Initialize Stage.

What would be appropriate to use in this scenario – Ticket or Change Stage?

The answer is Change Stage.

To achieve this requirement, we need to configure an optional action Reinitiate in the Review Stage.

Let us first see why Ticket cannot be used in this context. Let us create a ticket ReInitiate and set it in the first assignment of Initialize flow. In the post activity of ReInitiate, let us call SetTickets activity and pass ReInitiate as the parameter.

We can see that the flow does not move to Initialize Stage on Submit of ReInitiate. Why is it so? When the case is in Review stage, we can observe that pxFlow does not contain Initialize flow as one of the page group entries as Initialize Flow has got completed already.

Now, let us use OOTB Change Stage activity pxChangeStage in the post activity of Initiate local action and pass Initialize as the stage to be changed.

We can now observe that the case has moved to the Initialize Stage and is residing in Collect Loan Information assignment which is the first assignment in Initialize stage.

Scenario 2: Let us say there is a business requirement to enhance our case type with a second level of Approval in the Review stage. Once the case gets moved to Review, Loan Officer can approve or reject the case. When Loan Officer approves, the case needs to move to the General Manager for approval. On approval from General Manager, case will be assigned for Site Visit approval. During site visit, when Loan Officer selects Review option, the case needs to be re-approved by General Manager after reviewing documents that the Loan Officer will be attaching during the site visit.

What would be appropriate to use in this scenario – Ticket or Change Stage?

The answer is Ticket.

To achieve this requirement, we need to add another assignment to the Review stage to route the case to General Manager and on approval from General Manager case needs to proceed to Site Visit. Review ticket needs to be removed from first assignment and set in the newly introduced assignment so that case moves to General Manager on select of Review during site visit.

We cannot use Change Stage as we need to move to an assignment within the same stage. pxRestartStage could have been used in case if the business requirement is to start the Review stage from the beginning. Ticket would be the most viable option for this requirement.

Highlights of Tickets

Below are few of the highlights of tickets:

• Tickets can be used only to jump between flows that are present within pxFlow page group.

• If a ticket is set, it needs to removed. If two or more tickets are set, Pega will evaluate all the tickets to jump to a position in flow.

Pointers to Remember

• Tickets are used to process out of sequence events in a flow processing.
• In case design, Change Stage can be used to move to a different stage from the current stage, while, tickets are used to move back and forth between flows that are currently present in pxFlow page group.
• It is always a good practice to use SetTicket rather than Obj-Set-Tickets since SetTicket takes care of both setting and removing tickets.
• With Obj-Set-Tickets, we need to explicitly take care of removing the ticket if we no longer need the ticket to remain set. If two or more tickets are set, Pega will evaluate all the tickets to jump to a position in flow.
• Obj-Set-Tickets accept one or more tickets as parameters.

We are now at the end of the post. We hope you got the understanding of when and how to use Tickets in PEGA.

We are glad to publish detailed explanation on AllCoveredResolved ticket usage as requested by @ Vamsi. If you want us to publish any articles of your choice, please fill out this form & we will make sure it gets published.