- Usually all applications have at least a single business process.
- The business process use some sequence of events to complete the process.
Take Amazon as an example.
This is what happens, when we order a product in Amazon.
- You can see a work flow here. Not only this organization, every organization business process can be represented in flows.
Now, Amazon needs a Pega sales application to manage this business process.
- The ideal and best way to achieve this scenario is to use a case type.
- In Pega 7, there are some beautiful changes in case designer. Introduction of stages, steps greatly reduce the developer works. Let’s discuss more about cases in separate lesson.
This business process can also be achieved using flows.
In this post, I am going to explain how to configure a new flow.
I will explain all the available shapes and different scenarios in the upcoming posts 🙂
“One may wonder, we just configure the flow shapes, then how the business process is handled?”
Pega Handles it with ease 🙂
- All the available rules to support the flow shapes, routing, assignment are hidden within PegaRules application.
- Pega builts everything and all we need to do is apply our business logic using shapes.
- Pega does the rest by invoking the appropriate rules.
What is a Flow rule?
- A flow rule models the business process using shapes and connectors.
- Flow rule helps in achieving the sequence of events, every work item cross in their life cycle.
How do we configure a flow rule?
- Flow rule is of process category.
Create a new flow rule.
You can specify the additional configuration options:
- Screen flow
- Process flow
What is a Screen flow?
- Imagine you are filling an application form which contain n number of fields, you can represent these fields in series of screens (pages) for effective user experience.
- To achieve this we can use a screen flow to present series of assignments to a single user. User can go back and forth in the screens.
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.
What are the differences between Process flow and Screen flow?
Let us compare two scenarios:
Amazon sales process vs. filling online application form.
- Who can work on the above two process?
Many people are involved in sales process – Amazon service, Seller, Courier while only a single person should 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.
We will see about ‘screen flow’ with example in the upcoming posts.
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 the main difference is,
8. Screen flow cannot be a starter flow. They cannot create new work item.
Let us jump to the normal process flow we created before.
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.
In this post, I am going to explain only the configurations.
There are 4 main tabs:
- Diagram tab
- Design tab
- Process tab
- In this tab, you will specify the flow diagram.
- You got a tool bar to add or modify the shapes and layout.
- Draft button is provided to On/Off the draft functionality. If draft is On, then you can test the flow by adding shapes alone. No need to add the complete rules.
- Once rules are ready, remember to draft Off to validate all the shapes.
- + icon is used to add shapes within the flow rules. There are many shapes available in ‘flow rule’. It is a lengthy topic, I will take care of it in separate post.
Category – Read only. This will be based on what template you selected at the time of creation.
Flow-wide local actions –
Imagine you have a requirement, where you associate the interested people with the case. You can take this action throughout the case life cycle.
You can use 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 – opening a menu.
Step 3: Open the navigation rule – pyWorkActionsPerform
What do you see here?
Pre-Activity – pyWorkActionsPopulatePerform, opens the flow rule and append all the flow actions to the PageList property – pyFlowActionsList.
This is how the Other actions button load the local and flow actions in the menu.
Let’s go back to flow rule.
You can 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.
- 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.
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 applies to work class.
Create a new work object – On selecting this checkbox, this flow will create a new work item.
Then this flow can be called as 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 starting process.
Case creation settings
This block is visible only when you select, ‘Create a new case’ from the start settings.
Temporary Object –
- On selecting this checkbox, work item is created but with no ID. This work item will not be saved to Database.
I know, what you are thinking 🙂 Then, “why do we need this?”
Imagine, you are applying for an interview. A case is 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 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.
Let’s uncheck this and test.
Run the flow.
You will see that the new harness and the case ID are not created yet. You can try checking and testing from your end.
The Harness field, I marked in the picture is responsible to determine which harness should be displayed in the case creation.
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.
Let us test by closing the case when no assignment is being performed.
Still you will get the confirmation screen 😛
The reason is, this field applies only when flow started from create button and no assignment is found.
This same field is available in the flow action rule form.
Always this file takes precedence.
So, if you want to close the case/show harness after a last assignment screen, then use this setting.
Data Transform – You can specify a default data transform here.
If you leave blank, then default pyDefault will be called.
Work parties – Specify the work party to associate with the case.
For more details on ‘workparties’, kindly look at this post (http://myknowpega.com/2017/05/13/workparties/)
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.
- You can either set here or add in pyDefault Data Transform.
For more details on ‘SLA’, please see the post (http://myknowpega.com/2017/05/17/service-level-agreement/).
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.
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 post (http://myknowpega.com/2017/05/19/access-deny-privilege/)
No more… End of a long innings. See you soon in Flows part -2 🙂