Case Parallel Processing – Understanding

In this blog article, we will understand different ways to configure the parallel processing case flows.

Most of the business process will involve certain kind of parallelism in it case lifecycle at some point in the stage. For sure we will get into such a requirement when we want to use a Pega application case type to implement the business process.

It is necessary to understand the different possible and choose the best that suits your requirements.

On a high level, there are 2 ways through which you can achieve case parallelism

1. Multiple Parallel processes within a case stage.
2. Parallelism in a single process using different flow shapes

Let’s start with Parallel processes within a case stage.

a. Multiple Parallel processes within a case stage

Consider our claims application and investigation stage.

The documents can be validated by the Insurance company internally and parallel they can also check with external vendors for any fraudulent activity.

Both these processes can be go parallel in the Investigation stage. Let’s quickly identify how to implement it.

In the case designer, from the stage configuration, you can easily add a parallel process to the stage.

You can either create a new standard flow or new multi-form flow (screen flow).

Let’s create a standard process flow for the Fraudulent check. As soon as you add, you can see the Parallel mark added to the process

Now as soon as the case enters the second stage, you will see the parallel process spin up and you will see two active flows for the case in clipboard.

Quickly create a new case and enter the second stage.

You see the Fradulent check is already presented to the user screen (we didn’t configure the routing yet!)

The important configuration you need to check if open the case type rule, there you can find that the flows will be started automatically upon stage entry.

You see the first process is always – Start upon stage entry. The second process starts only after the first process – Start after a previous step. But the third process is also configured as ‘Start upon stage entry’.

You can also quickly test by creating a new case and entering to second stage.

In the pxFlow, you will already see two parallel processes running.

Now one important thing to note down is, that these processes are only parallel within the Investigation stage right?!!

It means the case cannot proceed further Investigation unless both the processes are completed! For me, this is not complete parallelism!! Can we achieve that?

Yes with different OOTB flow shapes, which we will see now.

b. Parallelism in a single process using different flow shapes

We are going to see about three parallel processing that can be used in a Flow rule.

1. Split Join
2. Split for each
3. Spin off

For this, we can use the third Approval stage, where the Claims request need to be approved by different people.

There can be two ways for approval to be sent to different people.

1. Varying approval process flow based on approver.
2. The same approval process flows for all the approvers.

Varying approval process flow based on approver

For the claims request, it needs to be approved my Workgroup or team manager, but on the reporting structure we may need two levels of approval.

Here you see one is a simple approval flow for Work group manager and other is a cascading approval flow on the reporting structure.

In this case, if we want to spin up different subflows parallel, then we can go with the Split-join shape in the flow rule.

How do we configure the Split Join shape?

In the flow rule diagram tab, open the shapes + icon, then advanced shapes and click and drag the Split join shape into the work area.

Double-click on the shape to explore the properties.

In Details block, you can configure the parallel processing details.

Join condition –

a) All – Only when both the Work group manager and reporting structure managers approve, the primary flow will resume and we can proceed with the next stage of payment settlement.

b) Any  – At least if any one of the managers approves, then the primary flow will resume and we can go to the payment settlement stage..

Say for example – Work group manager approves the case, then the assignment for reporting manager will be cancelled and the primary flow will resume to the payment settlement stage.

c) Some –

On When – You can specify a when rule to return to the primary flow.

On count – You can return to primary flow, when no of paths (say 1) results in flow status Resolved.

When the conditions are met, primary flow resumes and the other assignments get cancelled.

For example – let’s say we spin up three parallel process as split-join. Now in 3, any 2 count is approved, then we can consider it as an approval and proceed to next step. Like any 2 out of 3 approval needed conditions.

Subprocess tab

Specify a flow rule for this sub process –

Define flow – On which context the flow should run.

a) On current page – You can run the flow on current page.

b) On embedded page – You can run the flow on different page.

Normally we use this, when the flow is of another class.

c) On a specific work item – This is a bit tricky.

You can either specify a work party or a page name to identify the work item on which the flow should run.

Imagine you have a purchase request (parent work item) work item and a product order work item (child). If you are in the primary flow and want to run this Split Join flow in the child case, you can use this option.

Don’t get confused. We use it rarely. First, try testing using the same page context.

Flow input/output tabs

Tabs to support the input/output parameters for the flow rule.

Filter flow by – You can specify either process flow or screen flow.

Flow rule – Specify the flow rule.

You can add any number of parallel process here. Since the approval process are different, we need to add two different process here.

Advanced block

In the advanced block, you can specify the status as well as the tickets. Normal as we use in other shapes.

We are at the end of Split-Join configurations.

Same approval process flow for all the approvers

Let’s say for the same claims request case, if we have a simple approval flow for multiple approvers, then the same flow can be spun up for a list of people. Here the requirement can be to spin off flow for the workparties.

This can be achieved by using a Split-For-Each shape.

Now tell me. “What is the main difference you find in using Split-Join & Split -For each scenarios?”

Split Join – The approval subprocess is different for different people.

Split for each – The approval subprocess is the same for all people.

Remember Split Join & Split for Each are not pure parallel processing. The primary flow waits for sometime, before the conditions are met to resume.

 How do you configure Split for Each shape?

Follow the same steps to include a Split for each shape.

Double-click on the shape to explore the properties.

A few notable differences to split join are:

Join – You will have 4 options.

All, Any, Some – Same as Split Join.

Iterate – You can specify a when rule to exit iteration and return to primary flow. This option is because we need to mandatory use a pagelist property as the source. In our case a pagelist/page group property that holds the Workparty details.

Page property – Specify the Pagelist/Page group property.

Class – Page list defined class.

Filter flow by  – Process flow/Screen flow.

Flow name – Specify the flow name here.

When – You can specify a when rule to conditionally start the flow.

Note: There may be some scenarios, where we don’t want to start the flow for all the pages in the pagelist.

Assume, we have a workparty pagelist prioperty. It contains 5 results, but we need to start the approval flow only for mangers. You can use the when rule here to conditionally start the flow.

Page Group Iteration settings –

This appears only when we select Join – Iterate.

Applicable for Page group property.

Imagine, you used a page group property – pyWorkParty.

It contains two results:

1. pyWorkParty(Manager)
2. pyWorkParty(TeamLeam).

In the above picture, I mentioned subscript Manager. So the process flow starts only for pyWorkPage(Manager).

Exact match – Matches the subscript order exactly, no contains a match.

I hope you understood the Split-Join and Split-For-Each configurations more or less the same 😊

SpinOff

 Let’s say for the Claims request all the information is collected in the first process. The real Claims processing starts from there. Now let’s say we also want to use a parallel verification process which should not affect the primary flow. It means the case can fire and forget the verification process and then continue with the normal claims process.

 You can send the workitem to verification WB and continue working sales process.

The processing in verification WB is totally independent. It will never return to primary flow.

How do you configure the SpinOff shape? 

SpinOff is not a flow shape.

You can spinOff any subprocess using the SpinOff flow checkbox.

Include a subprocess shape and double-click on it to open the properties.

You can check the SpinOff flow checkbox to spin off any subprocess.

In the next blog article, we will have full hands-on in implementing all the parallel processing.