View the hierarchy of a user by highlighting the user and clicking Hierarchy.

Designing Human Tasks 27-19 4. Select the type, as shown in Figure 27–19 . Figure 27–19 Parameter Type

5. Click OK to return to the Human Task Editor.

Your selection displays in the Data section. 6. To edit your selection, select it and click the Edit icon in the upper right part of the Data section. Parameter Name Accept the default name or enter a custom name. This field only displays if Type is the selected parameter type. Editable via worklist Select this checkbox to enable users to edit this part of the task payload in Oracle BPM Worklist. For example, for a loan approval task, the APR attribute may need to be updated by the user reviewing the task, but the SSN field may not be editable. You can also specify access rules that determine the parts of a task that participants can view and update. For more information, see Section 27.3.11.1, Specifying Access Policies on Task Content. Note: You can only define payload mapped attributes previously known as flex field mappings in Oracle BPM Worklist for payload parameters that are simple XML types string, integer, and so on or complex types for example, a purchase order, and so on. If you must search tasks using keywords or define views or delegation rules based on task content, then you must use payload parameters based on simple XML types. These simple types can be mapped to flex columns in Oracle BPM Worklist. Table 27–5 Cont. Add Task Parameter Dialog Fields and Values Field Description 27-20 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite

27.3.6 How to Assign Task Participants

Figure 27–20 shows the Assignment section of the Human Task Editor. This section enables you to select a participant type that meets your business requirements. While configuring the participant type, you build lists of users, groups, and application roles to act upon tasks. Figure 27–20 Human Task Editor — Assignment Section You can easily mix and match participant types to create simple or complex workflow routing policies. You can also extend the functionality of a previously configured human task to model more complex workflows. A participant type is grouped in a block under a stage for example, named Stage1 in Figure 27–20 . A stage is a way of organizing the approval process for blocks of participant types. You can have one or more stages in sequence or in parallel. Within each stage, you can have one or more participant type blocks in sequence or in parallel. The up and down keys enable you to rearrange the order of your participant type blocks. For example: ■ You can create all participant type blocks in a single stage for example, a purchase order request in which the entire contents of the order are approved or rejected as a whole. ■ You can create more complex approval tasks that may include one or more stages. For example, you can place one group of participant type blocks in one stage and another block in a second stage. The list of approvers in the first stage handles line entry approvals and the list of approvers in the second stage handles header entry approvals. Each of the participant types has an associated editor that you use for configuration tasks. The sequence in which the assignees are added indicates the execution sequence. To specify a different stage name or have a business requirement that requires you to create additional stages, perform the following steps. Note that creating additional stages is an advanced requirement that may not be necessary for your environment. For more information about participant types, see Section 26.2.1.1, Task Assignment and Routing.