Flow Action – Usage and Configurations in Pega

In this blog article, we will see about different configurations and usage of a flow action rule.

What is flow action rule?

Flow action rule contains all the configuration points that describe how a user interacts with an assignment using work forms.

We know that every business process follows a certain flow. The flow starts at one point and ends at another point.

Let’s take a simple example of a vehicle servicing application.

If you see in the above flow, there are four actions to be performed.

Actions here refer to a user work form in which the assigned (responsible) people fills in to complete the work.

If we need to implement the above process in pega in a very simple manner, we can create a simple flow (case) with 4 assignments shapes. Assignment here refers to actions that need to perform

Note: In an ideal situation, we always create a case with steps for the above scenario 

Where do we refer to the flow action rule?

From the above explanation, you already know, where we can refer a flow action rule. Yes, you can refer it in a flow rule, to specific on the outgoing connector of the assignment shape.

Note: In screen flow, flow actions can be directly configured in the assignment shape!

Flow action rule can also be referred to as a local action, which we will see at the end of the post.

How to create a new flow action rule?

Records -> Process -> Flow action -> New

Create and Open

What are the configuration points in a flow action rule?

There are 5 main tabs

There are many tabs, but I am going to concentrate only one the 5 main tabs

1. Layout
2. Validation
3. Action
4. Security
5. HTML

Layout tab

It contains 3 blocks

a) Section configuration

It defines the section used to render the user work form.

In our scenario, we will build a flow action to collect the vehicle details. So my simple user form will contain 3 fields – Vehicle registration number, Purchase date and Customer name.

Please create or use the existing properties for this tutorial. I created a section that collects the vehicle details.

Let’s get back to the flow action rule and specify the section.

Page context –

We know that most of the rule are identified by their applies to class and pages define the class.

Use current page context – Uses the applies to class of the section rule we specify

Use data page –  You will get an extra field to specify the data page rule. By this way you can refer the section that is built on the applies to class of the data page rule.

Hope you are catching the point – dynamic referencing!!

Use clipboard page – Same like data page. Section can be referred using the applies to class of the clipboard page.

Use page defined by property – We know that property can be defined as a page. (Eg – address can be a page property that can include house number, street, state etc)

In our scenario, I will use the Use current page context.

Applies to – defines the class of the section rule.

Section name – Define the section name

Note: Section can be parameterised and you can specify the parameters in the flow action rule.

b) Refresh settings

Based on when rule or some conditional expressions you can refresh the section.

On specifying a refresh condition, you get an option to run either data transform or an activity rule before refreshing the section.

c) Security

With the required privilege, you can restrict this action only for certain users.  So that for other users who don’t possess the privilege the work form will be read only.

Say for example, in our case only the vehicle servicing agent can collect the details from the customer. We have already defined a flow action to perform collecting details. So, we need to secure the flow action!

Note: This is the first level of security to make the user form read-only. There are other security configurations for a flow action rule, which we will see later in the post.

Before securing, just run the flow action from Actions -> Run and see the work form is editable.

For testing, I just created a new privilege rule – UpdateVehicleDetails and included it in the flow action rule.

Save the flow action rule and run it.

You see the work form is read-only and secured!

Validation tab

The configurations here help to validate the user form.

Validate – Specify a validate rule.

In my scenario, I need to add a validation condition that the purchase date should not be a future date.

Note: Usually the naming convention of a validate rule can be Val+(flow action name)

I added a simple validation for the purchase date.

Now include the validate rule under validate tab.

Cool, now let’s test the validation rule.

Remember, the validation fires when the user click on the submit button.

So, to test this, include the flow action rule in any starter flow. For testing, I configured my flow as a starter flow and then run the flow.

Provide the purchase date as a future date and click on submit

You see the error message we specified in the validate rule.

Update status upon successful validation?

There may be some requirement, where you need to update the case status when the validation is successful or all the mandatory criteria are captured.

In our scenario, I will update the status to Pending-Fulfillment when the vehicle details are captured.

Run the starter flow again and provide the valid vehicle details. Click on submit.

You see the status changed to Pending-Fulfillment

Action tab

You have 5 blocks to configure

1. Pre-Processing and 2. Post processing

The name itself identifies the responsibility of these blocks.

You can take pre actions before the screen is rendered and  perform the post actions once the user submits the form.

Actions can be three ways.

You can run a data transform with parameters or run an activity with parameters or run robotic automation!

For testing, I created a data transform rule that presets the purchase date to today’s date.

Note: For naming convention, use pre(flow action name) and post(flow action name)

Now specify the data transform rule in the pre-processing block and save the rule. Run the starter flow to test.

You see the purchase date is prepopulated to today’s date.

Post processing is the exact opposite to pre-processing with few additional configurations.

Savable data pages – With pega 7.4 version, you can directly save the data pages and commit the instances to DB. You can specify the savable data pages that can be saved once the flow action is completed.

Apply Cost – This is similar to urgency, where you can specify a numeric value. I am not quite sure of the exact use case for this field 🙂

Back to back processing configuration –

What is back to back processing?

Say in our scenario, The CSR capture the vehicle details and if we have another form where the CSR needs to capture the customer details, then that can be called as back to back processing. It means after this flow action, the user needs to continue work on.

Look for an assignment to perform – So here on completing the current assignment, the system checks if there are next assignment to perform in the same case within the same flow execution.

If not found, look for assignments in other flows on same case – The description speaks! The system checks assignments on the other flows in the same case.

If now found, look for assignments in flows on the parents’ case – same like option 2, but it also checks on parent case.

For each also consider assignments in work queues – here the system searches assignments in the work queues (workbasket) associated with user workgroup. This is applicable only when the first option is selected.

For testing, I selected only the first checkbox.

Now, run the flow and check if the system looks for the next assignment as soon as you complete the current flow action.

In the above picture, you can see the system checks for the next assignment – order spare parts that are assigned to the same user!

Now think of a scenario, where the ordering spare parts need to be completed only after 3 days by the same user. In this scenario, you don’t have to provide the user with the next screen as soon as he completed collecting details.

To achieve this, just remove the first checkbox, so that the system will never look for an assignment in the same case.

You see when you unselect the first checkbox, you will not see the other options as well!

Now save the flow action rule and run the flow.

Now, you see the system doesn’t look for the next assignment and it just shows you the confirm harness.

Why confirm harness?? The configuration stays just below

If an assignment is not being performed –

You get 4 options

Show harness – by default confirm harness, you can also specify other harnesses as well

You get do get next work to pull the next work object.

Close the work object – you can just close the case (try testing this option on your own)

Actions buttons

You can hide the default action buttons. On selecting this, the default submit button will be hidden. You need to include your own custom button in the flow action section.

Note: The default submit button, always performs finish assignment action set.

Customize the action button labels –

The above default buttons contain the default labels.  You can customize the button labels.

For testing, I just change the Submit button label to Prem Submit.

Save and run the starter flow again.

You can see the customized label.

Indicator

Flow actions can be used locally. It means it can be used outside flow rule, from click of button, link etc.

You got 3 options

Local action – It can be used to update the case, typically from a modal dialog which get launch from a click action set.  For eg – add attachments, etc

Connector action – Typically used in the flow rule connector shape, to update and advance the flow

Local and Connector – This is default selected, so that the flow action can be used in both ways 🙂

Disqualify this action from bulk processing –

Bulk processing can be used to perform the same action on multiple cases. On selecting this option, the flow action will be excluded as an available action for bulk processing.

To know more about bulk processing, please visit the below pdn link

https://community.pega.com/sites/default/files/help_v731/case-management/case-manager-portal/bulk-actions/cm-running-flow-actions-in-bulk-tsk.htm

Security tab

The configuration in the security tab is responsible for two functionalities

1. Restrict users to access the flow action based on privileges or when rules.
2. Auditing / logging the usage of this flow action

1. Restrict users to access the flow action

Think of the requirement, the vehicle servicing can be cancelled at any point of time in the flow. Remember Cancel is also a flow action/connector action ( or can be considered as a local action).

First, let’s see how we can implement cancel as a connector action from the assignment shape.

Add another connector from the first assignment shape.

Include the flow action – Cancel in the connector shape.

Now you may get a question like 2 connectors with two flow actions are coming out from a single assignment shape, so which flow action will get priority and how the other action can be accessed.

The default flow action presented to the user will be the connector with the highest likelihood.

Likelihood – In the range of 1-100. I gave the cancel action likelihood as 10 and CollectVehicleDetails action likelihood as 90. So the CollectVehicleDetails, the action with the highest likelihood will be default presented to the user and the other actions can be found in the action button!

Save and run the flow.

You can click and perform the cancel action!

Let’s see how we can implement the cancel action as a local action.

a) Add local actions only for the particular assignment shape

Double click on the assignment shape, to add one or more local actions in the assignment shape.

b) Add flow-wide local actions

In the flow rule, under the design tab, you can add flow-wide local actions.

Save the flow rule and run. You will see cancel option in all the 4 assignments throughout the flow.

Note: Sorry that I didn’t use case designer. This is much simpler in case designer as well. You can add local actions in step, stage as well as case wide local actions.

In my requirement, I can cancel the vehicle servicing at any point of time!. So I implemented the cancel action as flow wide local action. Now the next requirement is, only certain privileged users can perform the cancel action!

Now we are back on track. Use the security tab in the cancel flow action and specify a privilege.

I saved as the OOTB cancel flow action in my application ruleset and then created a new privilege and added the same. Save the flow action rule once done.

Now run the flow and check the actions button.

Cancel action is missing because I don’t have the privilege added to my profile.

This makes the cancel action invisible to the unprivileged users.

The same requirement can be achieved using when rule instead of privileges.

So using when rule, only when all the conditions evaluate to true, then the action will be visible at run time.

Auditing / logging the usage of this flow action

On enabling the auditing functionality, you can specify the when condition as well as the audit activity. You can use the default activity Audit populated to create instances of Log-DataAccessAudit.

HTML tab

There are 2 blocks.

• UI generation options
• HTML source

UI generation options

UI type – you get three options

a) Reference section

b) Reference HTML source (deprecated) – Non-auto-generated flow action

c) NO UI – It means this action doesn’t require any user input!

Enable client-side validation – Name speaks, on checking this, client side validation will be enabled for the user work form.

Enable expression calculation – On enabling this, declare expressions can be fired with in the work form target properties.

It is good to enable both the options!

Note: Enable client-side validation and expression calculation is available in the harness rule form as well.

If your client-side validation or declare expression didn’t work well, you can take a look at these configuration points!

HTML source

It displays the generated HTML source from the flow action rule.

How to use a flow action rule as a local action?

Flow action rule can be considered as a local action and can be launched from any action set, preferably On click.

How to implement on click local action

Step 1: For testing, place a button on the collect vehicle details screen.

Double click on the button properties and add an On click event with Launch: Local action as the action

Step 2: You can configure how and when a local action can be launched.

Target – specifies how to launch a local action.

When – Conditions when met true, local action will be launched.

I am going to try target as modal dialog.

Step 3: Save the rule and run the flow.

Step 4: Click on the button to launch the local action.

You see the configured local action is rendered in a modal dialog.

Please explore the other options from your end!

We are at the end of the article. I believe you understood the main configuration points in the flow action rule.