Flow rule in Pega – Usage and Configurations

In this blog article, we will understand about the different configurations in a flow rule.

Keeping the expectations, we will not look into different flow shapes in this blog article. We will discuss all other flow configurations except the different shapes 😊

I would recommend you to visit my previous blog article on Case Manage Introduction and Configuring Stages, Processes and Steps.

Hope you are familiar with the below Case hierarchy structure.

Business requirement on Home Insurance Claims – Consider XYZ company provides Home insurance polices. Home Insurance policies can provide coverage and compensation to the losses or damages occur to the insured house. The customers can apply for the compensation by creating a Claim request with the Insurance Organization. The claims request can eventually be processed by the company.

We already defined different stages, processes and steps for this Claims Request case lifecycle.

We also talked about different processes at different stages.

Let’s consider the second stage – Investigation where there are 2 processes involved – Request Investigation and Onsite Investigation Process.

We also know that Pega creates a flow rule for every process we add inside the stage.

Let’s verify the Request Investigation process and dig deep into the flow rule configuration.

Open the process from the case designer.

This should land you the flow rule configuration in the designer studio.

What is a Flow rule?

A flow rule models the business process using shapes and connectors.

Flow rule helps in executing the sequence of events, that every process in a case includes.

How do we Create and  Configure a flow rule?

Flow rules can be created in two ways.

1. Automatic creation – As we saw before, whenever we add any new process in the case stage, Pega automatically creates a flow rule at the backend.

2. Manual creation – Flow rule is of process category.

Just like other rule creation, you can simply create a new flow rule.

You can specify the additional configuration options:

By Default all flow rules will be created as standard process flow, but you have an additional configuration option with a radio button, where you can decide if you want to create a screen flow.

This opens up the discussion of different types of flow rules.

Process flow Vs Screen flow.

What is a Screen flow?

Screenflow is discussed in detail in a separate blog article

Imagine you are filling out an application form which contains n number of fields, you can represent these fields in a series of screens (pages) for an effective user experience.

To achieve this we can use a screen flow to present a series of assignments to a single user. Users can go back and forth on the screens.

In a low-code context, this can also be referred as a Multi-form process. I hope you can remember the discussion from another blog article on case processes.

It is also good to know, that Pega by default designs the create stage to be on a Multi-form process, which in turn translates to Screen flow.

You can see only in the first process of create stage (first stage), you get the option of adding only Form-steps

You can also quickly open the process behind the first process, you will find the configuration that the flow is configured to be of screen flow.

What is a Process flow?

This can be a starter flow or a simple flow to support business process. Here users are able to route the tasks to other users, worklist, workbasket and all other functionalities.

All other flows except screen flows can be considered standard process flows 😊

What are the differences between Process flow and Screen flow?

Let us compare using two business scenarios and ask some critical questions on the design.

Amazon sales process vs. filling out online application form.

Who can work on the above two process?

Many people are involved in sales process – Amazon service, Seller, Courier while mostly a single person will be involved to fill out the online application form.

From this, you can differentiate process and screen flows in 2 ways:

1. Process flows can be routed to many people to work on. In Screen flows, only a single people can work.

2. In process flows, routing can be configured in assignment shapes, while in screen flows, routing is configured only in the start shape. (Yes, we need to decide before start filling an application form).

How the form should look for the two flows?

Harness determines the presentation of the form. In Amazon sales process, the forms provided to people will be different from one another, but online application form will be uniform in all the pages.

From this, you can differentiate process and screen flows in 2 ways:

3. You can have different harness for different forms in process flow, while you have a uniform harness for screen flow.

4. You can specify the harness (tab or tree) in the screen flow start shape, but you can’t do the same in process flow.

You can check the start shape configurations for screen flow.

Other differences are,

5. In process flow, you can specify the flow actions in the connector shape, while in screen flow, you can specify the flow action in assignment shape.

6. You have the option to go back and forth in screen flow, but you can’t do the same with process flow.

7. Advanced shapes are not supported by Screen flows except split for each.

And finally the other main difference is,

8. Screen flow cannot be a starter flow. They cannot create new work item.

Okay now we know about different types of flow rule.

Let’s use the already created flow rule and explore the different configurations within the flow rule.

As soon as you create a flow 3 shapes are available – a start shape, an assignment shape and an end shape. You can extend and include new shape to support your business process.

What are the configurations in a flow rule?

There are 3 main tabs:

1. Diagram tab
2. Design tab
3. Process tab

Diagram tab

In this tab, you can draw the business process using flow shapes and connectors. More like a flow diagram.

Draft mode – You can already see the draft mode is ON for the flow rule.

Note: At the end, you should always switch off all the draft flows and remove the draft configuration before you go for production.

This can come in handy only in a lower environment when you want to design without big blocker errors.

Just click to switch off the Draft mode.

You see there is a design-time error already saying flowaction rule name is not configurated.

Note: Pega can automatically create flowactions when you configure views from steps in the case designer.

We can put the draft mode on again.

You got a toolbar to add or modify the shapes and layout.

+ icon is used to add shapes within the flow rules. There are many shapes available in ‘flow rule’. It is a lengthy topic, deserves a separate blog article.

Design tab

Category – Read only. This will be based on what template you selected at the time of creation. It can be FlowStandard or Screen flow.

Flow-wide local actions –

Imagine you have a requirement, where you can add the case stakeholders at any point in the case lifecycle. You can easily achieve this using Case-wide local actions.

But in case if you need the flow actions, only to be available for the specific process or flow, then you can include the flow-wide local actions.

Now, let us check the user portal.

Let me say about how this works.

Step 1: Use live UI for the other action button. Open the section and button properties.

Step 2: You will an On click action set – Which pre-populates the data in the clipboard and  opens a menu

Step 3: Open the navigation rule – pyWorkActionsPerform

What do you understand here?

Pre-Activity – pyWorkActionsPopulatePerform, opens the flow rule and append all the flow actions and local flow actions to the PageList property – pyLocalActionsList.

This is how the Other actions button load the local and flow actions in the menu.

Let’s go back to the flow rule.

As you can add multiple flow actions, you can easily modify the order in which these local actions should be present in the user form.

Display actions in alphabetical order? – sorts the local actions and displays in alphabetical order in other actions button.

Display these actions first? – You can also display the same order we provide in this field. The same order will be reflected in User portal.

Tools

You have few tools to publish this flow or to invoke this flow from external services.

Generate services – This is mainly used to invoke this flow from any Pega service rule.

Let’s test it.

Click on generate services. It will open up the Service wizard.

Complete the wizard. Each step will be explained in Integration posts.

After you complete the steps. Check the Service-SOAP rule.

You will see the Service using OOTB service activity – svcAddWorkObject to invoke the flow rule we created.

Process tab

Start settings

For a change, let’s see the section Pega used in Designer studio.

Process Commander internal flow – you can open the property form and check why it is used.

Yes, if checked this flow will not write history. Also, note that this checkbox is visible for all flows.

‘pySystemFlow’ property contains the data for this checkbox.

This value is set, when you create a new flow & default will be false. You can check view xml from the Actions button and check this property value in the rule form.

Similarly, you can check for all the fields in the flow rule form. 🙂

Can be added to a work object – On checking this, the flow can be invoked on another work item through other actions button.

Note: This checkbox will not be visible if there is already a case available in the flow that applies to the work class.

Important note: With the Pega latest version, 99% of the time, we will be using the case type so starter flows will not be used. It can be applicable to legacy applications.

Create a new work object – On selecting this checkbox, this flow will create a new work item.

Then this flow can be called a starter flow.

pyCanCreateWorkObject – Note this property. We will see its usage later in this lesson.

This checkbox will not be visible if there is already a case available in the Applies to class.

Document as Starting process – This checkbox is not that much important. When checked, this flow can be added in the application documentation as a starting process.

Case creation settings

This block is visible only when you select, ‘Create a new case’ from the start settings.

Again the case creation block is outdated and is not used for new case types!!

Temporary Object – (This is totally deprecated from Pega 8.4 version)

On selecting this checkbox, the work item is created but with no ID. This work item will not be saved to the Database.

I know, what you are thinking. Then, “why do we need this?”

Imagine, you are applying for an interview. A case was initially created for you as I-1, but sorry, unfortunately, your profile is screened now. They have to resolve the case as cancelled.

If the organization don’t want to keep a record of these, then they can create a temporary object initially. Once you are qualified from the screening, they can create a new case ID and work on the Interview process.

Remember, you can persist any temporary object, anytime in the flow using it as an advanced shape ‘Persist a case’.

Skip create harness –

Imagine the same example above, the organization needs you to fill in a form before starting the interview process. Case ID will be created only after submitting the form.

If you check this checkbox, then no create harness will be shown. A case ID will be created.

Look for an assignment to perform – Make sure you check this checkbox. Default selected.

On checking this, Pega invokes a search to identify any open assignments for the same case in the work list. If yes, then the assignment will be presented to the User.

Also consider an assignment is workbasket – This is visible only when look for an assignment to perform is checked.

Here, Pega extends the search to the user available workbaskets.

If an assignment is not being performed? –

You can either show the harness or close the case.

If you select show harness, then specify a harness – Usually Confirm harness.

This same field is available in the flow action rule form.

Always the flow-action configuration takes precedence.

So, if you want to close the case/show harness after the last assignment screen, then use this setting also in the flow action rule.

Data Transform – You can specify a default data transform here.

If you leave blank, then default pyDefault will be called.

Work parties – Specify the stakeholders/work party to associate with the case.

For more details on ‘Workparties’, kindly look at this article.

Supporting Process Settings

What is a supporting process?

Supporting process is specified in case type.

Supporting process appears in the Add work – Other actions menu. You can start a support case while working on the main case.

Look for an assignment to perform – Same as explained above.

Also consider an assignment is workbasket – Same as explained above.

This field holds the flow level SLA. This field can also be configured when you specify the process level SLA configuration

For more details on ‘SLA’, please see the article.

Start Conditions

You can specify a when rule to authorize creating a new flow.

Let’s test. I used never condition. Now, run the flow.

On clicking create button, you will get the error shown below.

Security

You can also restrict creating the flow using authorization rule – Privilege.

The users should contain the above privilege to start the flow. If many used, then he/she should contain at least one privilege to start the flow.

For more information on ‘privilege’ visit my another article.