Workflow participants

A workflow might contain activities that require manual intervention or input by a user before it can be completed. This user is called a workflow participant.

When an activity requires an action before it can continue, an activity to-do item is assigned to the participant. The item occurs in the Activities to-do list of the participant, who can view the item the next time the participant logs on to IBM Security Identity Manager. This to-do item might consist of a participant who approves or rejects a request. The to-do item might provide the activity with information for it to process, or complete a manual task outside of the system. When a participant completes the to-do item, the activity can proceed.

Workflow participants must have an ISIM account to respond to approval requests and requests for information.

To respond to work order requests that require completion before the workflow continues, a participant must have a valid email address or an ISIM account.

For each activity that requires a participant, we can also specify an escalation participant.

When we specify an escalation participant, you define a time limit used to determine when the request is escalated. If the original participant cannot be resolved or does not respond within the specified time, the escalation participant is notified. If for any reason the participant and the escalation participant cannot be resolved, the System Administrator group becomes the workflow participant.

A manual activity has performance considerations if we select a participant of type ITIM Group or Organizational Role. A group or role with a large membership, greater than 1000 members, might cause problems when the system creates activities for each individual.

Additionally, we might redesign a workflow process that authorizes many individuals to approve an activity. For example, we might select the participant for a workflow activity. An approval that goes to an ITIM Group or an Organizational Role sends the approval to each member of that group or role. The activity is completed as soon as any one member of the group or role (in this example, containing over 1000 members) acts on the approval.

• Workflow participant types
  Workflow participants can be specified by the participant type, including system-defined participant types and custom (user-defined) participant types.
• Custom workflow participants
  We can define custom workflow participants with JavaScript code.
• Self-approval for requester
  When the enrole.workflow.selfapproval is set to true, requesters can approve their own requests.
• Customized self-approval for requestee and requester
  Administrator can define the customized self-approval by requester and requestee by using JavaScript code.
• Skip approval for requester property
  In some cases, the requester of an activity can also serve as a workflow participant.
• Disable requestee or requester approval
  In some cases, the requester or requestee of an activity can also serve as a workflow participant for an approval.
• Skip delegation when requestee is the delegated approver
  When an approver delegates the approval activity, the delegatee in some cases might end up to be the requestee in the request.

Parent topic: Workflow planning