In this blog series (part1, part2) I am covering step-by-step how to build and deploy an automated business process using the process cloud service.
At this moment we can visually understand the workflow, but with the exception of the Form Start activity there is no real implementation underneath the BPMN notation.
Approve
This activity is meant to define the who, the how and the when about the approval step.
An assignee can be a person or a group. The choice here is whether the approval should be handled in sequence, parallel or with a single assignee.
For this use case I pick the “Any Single Assignee”.
Assignees
You can assign the human task to a specific user, to a group of users, to the users in a certain role.
You have 2 options:
- Build the list with names and expressions
- Lane participants
With Names and Expression you can define user/group that is responsible to act (approve/reject) the requests. In the Single Assignee option, the first one to act on the request will make the process continue.
The second option is Lane Participants , where the actual participants can be defined at a later stage in the runtime configurations.
Actions
APPROVE and REJECT are the default Actions. Other actions can be specified, such as HOLD and MOREINFO. They need to be all CAPS and separated with a comma.
Pressing the little person icon on the right side brings even more Actions. By default they are all selected.
Task Identifier
The title and the summary are used to easily identify the task at end. They will appear in the user’s task list, and can be used for filtering.
Reminders
What if the approver(s) does not act on the request? Well, for that we have reminders, which allow to configure intervals of actions to remind users.
- No Reminder
- Remind Once
- Remind Twice
- Remind Three Times
You can then specify the interval in month/day/hour/minutes.
Escalation
What if the users don’t act even with the reminders? For that we have escalations. The escalation path (as in, who will receive this) can be defined in the run time configurations.
Here one can decide how may escalation and the interval for them.
This activity also allows to choose for expiration, or renewal.
Notification
Notification is a crucial piece here, as it enables the communication to the involved parties in the process.
“send a notification email to the task assignee when an event such as assignment, approval, escalation, reminder, and reassignment occurs. A notification email contains outcomes defined for a task, such as Approve or Reject. Assignees can click on these outcomes to complete tasks using their email clients, without having to sign in to the application.”
Decision Gateway
In the decision gateway we capture the action from the Approve activity and decide which path to take based on the decision value (APPROVE/REJECT).
Conclusion
We now have a solid implementation of the business process, with a starting Form that will capture the information to be send for approval.
We configured the Assignees, Approvers, Reminders, Escalations and Notifications, all within the same activity.
Next we should put this first draft to testing!
Hi Daniel,
Thank you for you blogs!!
Could you please explain step by step process of how to embed these PCS Forms in external application (or) in VBCS application.
Thanks in Advance!!
Hi Jagadeesh, the last post on this series will cover that topic – I have it in my backlog 🙂
Thank you Daniel for your quick response.
When can we expect the next blog in the series?
The next couple of week I ll post 2 more. But for the embeded vbcs/saas I need to still work on that.