Reassigning Tasks (Scenarios)

In the following examples, the Company Administrator is the user who has permissions to reassign the tasks.

Case 1: Selected new assignee is a CC user

  1. Business Process record R1 is assigned to user A and has CC'd user B.
  2. User A has been inactivated.
  3. Company Administrator has now reassigned this task to user B.
  4. User B receives the task reassignment notification in addition to seeing the task in the Tasks log.
  5. The system removes the notification for this task, which the user B had received because of being a CC'd user, from the Notifications log.

Case 2: Selected new assignee is not in the Workflow (WF) setup

If the selected assignee is not in the WF setup, the user will still get the reassigned task. This means that the task will be seen in the Tasks log.

Note: Reassigning the task does not add the user to the WF setup. This action has to be performed by the administrator who is setting up the workflow setup. Similarly, the user will not have navigation level permissions to the Business Process log that the task belongs to. This action again has to be performed by the administrator.

Case 3: Selected new assignee had previously declined the task

If the selected new assignee had previously declined the task, then post reassignment, the task will be seen in the Tasks log.

Assumption: The workflow setup allows declining of the task.

Case 4: Step Revisiting option is set to Include only previous action takers

  1. Business Process record R1 that was created by user A is assigned to users B and C.
  2. User A has been inactivated.
  3. User B accepts the task and routes the record to step A.

    Because Assignees is set to Dynamic with match step <Creation> at step A, the system automatically notifies the Company Administrator and asks the administrator to transfer ownership of the record.

  4. Company Administrator changes the ownership to user D.
  5. User D receives the task notification, accepts the task, and routes the record to step C.
  6. At step B, Assignees is set to Dynamic with match step <any step> and assignee who took action on that match is inactivated.
  7. User C accepts the task and routes the record to step B.

    Because Assignees is set to Dynamic with match step <any step> at step B and the assignee who acted on that match step is Inactive, the system displays a message that lets user B select another user based on the filter conditions defined for the workflow setup.

  8. User B selects user E for step B.
  9. User E receives the task notification.

Case 5: Single Completion policy - Non-participating assignee has been inactivated

A non-participating assignee is one who has not acted on a task. When such a user is inactivated, the in-flight records that had this user in one of the steps will not be seen in the Tasks reassignment log.

Case 6: Completion Policy - All Consensus

  1. Business Process record R1 is assigned to users A, B, and C.
  2. User A accepts the Task and routes the record to step A.
  3. User B declines the task.
  4. User C has been inactivated.
  5. Company Administrator reassigns the Task of user C from the Task Reassignment - Inactive User Tasks log to user D.
  6. User D accepts the Task and routes the record to step B.
  7. The system routes the record to the resolving action because the users have taken different actions.

Case 7: Completion Policy - All Majority

  1. Business Process record R1 is assigned to users A, B, and C.
  2. User A accepts the Task and routes the record to step A.
  3. User B accepts the Task and routes the record to step B.
  4. User C has been inactivated.
  5. Company Administrator reassigns the Task of user C to user D.
  6. User D accepts the task and routes the record to step B.
  7. The system routes the record to step B because the majority of the users took the action of routing it to step B.

Last Published Wednesday, July 2, 2025