Introduction to Human Workflow

26-6 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite

26.2.1.1.4 Ad Hoc Routing In processes dealing with significant variance, you cannot

always determine all participants. Human workflow enables you to specify that a participant can invite other participants as part of performing the task. For more information, see Section 27.3.7.1.1, Allowing All Participants to Invite Other Participants.

26.2.1.1.5 Outcome-based Completion of Routing Flow By default, a task goes from starting

to final participant according to the flow defined in the routing policy as shown in Figure 26–2 . However, sometimes a certain outcome at a particular step within a task’s routing flow makes it unnecessary or undesirable to continue presenting the task to the next participants. For example, if an approval is rejected by the first manager, it does not need to be routed to the second manager. Human workflow supports specifying that a task or subtask be completed when a certain outcome occurs. For more information, see Section 27.3.7.1.2, Stopping Routing of a Task to Further Participants.

26.2.1.2 Static, Dynamic, and Rule-Based Task Assignment

There are different methods for assigning users, groups, and application roles to tasks. ■ Assign tasks statically You can assign users, groups, and application roles statically or by browsing the identity service. The values can be either of the following: – A single user, group, or application role for example, jstein, CentralLoanRegion, or ApproverRole. – A delimited string of users, groups, or application roles for example, jstein, wfaulk, cdickens. ■ Assign tasks dynamically You can assign users, groups, and application roles dynamically using XPath expressions. These expressions enable you to dynamically determine the task participants at runtime. For example, you may have a business requirement to create a dynamic list of task approvers specified in a payload variable. The XPath expression can resolve to zero or more XML nodes. Each node value can be either of the following: – A single user, group, or application role – A delimited string of users, groups, or application roles. The default delimiter for the assignee delimited string is a comma ,. For example, if the task has a payload message attribute named po within which the task approvers are stored, you can use the following XPath expression: – task:tasktask:payloadpo:purchaseOrderpo:approvers – ids:getManagerjstein, jazn.com This returns the manager of jstein. – ids:getReporteesjstein, 2, jazn.com This returns all reportees of jstein up to two levels. – ids:getUsersInGroupLoanAgentGroup, false, jazn.com This returns all direct and indirect users in the group LoanAgentGroup. Getting Started with Human Workflow 26-7 ■ Assign tasks with business rules You can create the list of task participants with complex expressions. The result of using business rules is the same as using XPath expressions.

26.2.1.3 Task Stakeholders

A task has multiple stakeholders. Participants are the users defined in the assignment and routing section of the task definition. These users are the primary stakeholders that perform actions on the task. In addition to the participants specified in the assignment and routing policy, human workflow supports additional stakeholders: ■ Owner This participant has business administration privileges on the task. This participant can be specified as part of the task definition or from the invoking process and for a particular instance. The task owner can act upon tasks they own and also on behalf of any other participant. The task owner can change both the outcome of the task and the assignments. For more information, see Section 27.3.4.6, Specifying a Task Owner to specify an owner in the Human Task Editor or Section 27.4.4.2, Specifying a Task Owner to specify an owner in the Advanced tab of the Human Task dialog. ■ Initiator The person who initiates the process for example, the initiator files an expense report for approval. This person can review the status of the task using initiated task filters. Also, a useful concept is for including the initiator as a potential candidate for request-for-information from other participants. For more information, see Section 27.4.3.2, Specifying the Task Initiator and Task Priority. ■ Reviewer This participant can review the status of the task and add comments and attachments. ■ Admin This participant can view all tasks and take certain actions such as reassigning a test, suspending a task to handle errors, and so on. The task admin cannot change the outcome of a task. While the task admin cannot perform the types of actions that a task participant can, such as approve, reject, and so on, this participant type is the most powerful because it can perform actions such as reassign, withdraw, and so on. ■ Error Assignee When an error occurs, the task is assigned to this participant for example, the task is assigned to a nonexistent user. The error assignee can perform task recovery actions from Oracle BPM Worklist, the task form in which you perform task actions during runtime. For more information, see Section 27.3.7.4, Configuring the Error Assignee.

26.2.1.4 Task Deadlines

Human workflow supports the specification of deadlines associated with a task. You can associate the following actions with deadlines: 26-8 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite ■ Reminders: The task can be reminded multiple times based on the time after the assignment or the time before the expiration. ■ Escalation: The task is escalated up the management hierarchy. ■ Expiration: The task has expired. ■ Renewal: The task is automatically renewed. For more information, see Section 27.3.9, How to Escalate, Renew, or End the Task.

26.2.1.5 Notifications

You can configure your human task to use notifications. Notifications enable you to alert interested users to changes in the state of a task during the task lifecycle. For example, a notification is sent to an assignee when a task has been approved or withdrawn. You can specify for notifications to be sent to different types of participants for different actions. For example, you can specify the following: ■ For the owner of a task to receive a notification message when a task is in error for example, been sent to a nonexistent user. ■ For a task assignee to receive a notification message when a task has been escalated. You can specify the contents of the notification message and the notification channel to use for sending the message. ■ Email You can configure email notification messages to be actionable, meaning that a task assignee can act upon a task from within the email. ■ Voice message ■ Instant messaging IM ■ Short message service SMS For example, you may send the message shown in Example 26–1 by email when a task assignee requests additional information before they can act upon a task: Example 26–1 Email Message For me to approve this task, more information is required to justify the need for this business trip During runtime, you can mark a message senders address as spam and also display a list of bad or invalid addresses. These addresses are automatically removed from the bad address list. For more information about notifications, see the following: ■ Chapter 16, Using the Notification Service ■ Section 27.3.10, How to Specify Participant Notification Preferences