Consideration using a use case where the customer is updating the user assigned to a DCR task when the changed assignee is not the original creator?

Question

Background Context
In the current DCR (Data Change Request) setup, specific users are designated to validate changes to certain attributes of an entity. For instance:
 

• Users A and B are responsible for validating location data.
• Users C and D are responsible for validating billing data.

If a change is suggested to the company’s address, either user A or B should be notified. Similarly, if a change is suggested to the tax ID, either user C or D should receive the notification and be responsible for accepting or rejecting the change.
 

Development to Date
The implementation is based on the out-of-the-box DCR workflow, with one key modification:
 

• Candidate Groups were altered to assign a role that only a dummy user possesses. This ensures that the DCR task is initially assigned to the dummy user.

Following the task assignment, an automated recipe is triggered. This recipe performs the following actions:
 

1. Retrieves the details of the DCR.
2. Identifies the attribute that has been modified.
3. Calls the /groups/{groupID} endpoint to obtain a list of users from a custom group (e.g., SCH_LOCATION_REVIEWERS for an address change).
4. Uses a Python script to randomly select one user from the returned list.

5. Attempts to reassign the task to the selected user via the following API:

   PUT /workflow/{tenantId}/tasks/{taskId}

   Reltio Workflow API – Update a Task

However, when attempting to reassign the task, the following error message is returned:
 

400 Bad Request: {
  "status": "failed",
  "error": {
    "errorCode": 10090,
    "errorMessage": "User 'luis@clinic.com' does not have necessary permissions to become an assignee of the task #12172704.",
    "errorData": {
      "exception": "com.reltio.workflow.core.KeyedException: User 'luis@clinic.com' does not have necessary permissions to become an assignee of the task #12172704."
    }
  } } 

Multiple scenarios were tested, including:
 

• Reassigning to different users.
• Reassigning to users with admin privileges.
• Reassigning to users from the same group.

Additionally, an attempt was made to modify the candidate group using the /processInstances endpoint with the following request:
 

POST https://<workflow-host>/workflow-adapter/workflow/{tenantId}/processInstances
Content-Type: application/json

{
  "processType": "dataChangeRequestReview",
  "businessKey": "changeRequests/{yourChangeRequestId}",
  "objectURIs": ["changeRequests/{…}", "entities/{…}"],
  "variables": {
    "groups": "ROLE_AMC_REVIEWERS"
  } } 

The workflow model includes the following logic for group selection:
 

${execution.hasVariable('groups') ? groups : "SCH_DATA_STEWARD"}

Despite this approach, the same error message persisted when the task was reassigned.
 

Answer

Is there a way of reassigning the task to another user?
 
Yes, but only under these conditions:
 

• The target user must belong to the candidate group (role) defined in the user task at the time of creation.

• If your BPMN model uses the expression:

  ${execution.hasVariable('groups') ? groups : "SCH_DATA_STEWARD"}

  Then:

  • You'll need to set the groups process variable before the task is created.
  • If you do not set it in time, the task defaults to the "SCH_DATA_STEWARD" group, and that group cannot be changed afterward.

So:
 

Reassignment is possible only to users who are members of the current task's candidate group (e.g., SCH_DATA_STEWARD).

Which ROLES should the user have?
 
A user must have:
 

1. The role used in the candidate group for the task. In your case, this is SCH_DATA_STEWARD (confirmed via Jeremy’s assignment and task behavior)
2. Additional roles to allow interaction with workflows:
   • ROLE_WORKFLOW
   • ACCEPT_CHANGE_REQUEST
   • ROLE_REVIEWER

These roles are typically required to see and act on DCR workflow tasks.
 
Therefore:
 

The user must have the candidate group role (e.g., SCH_DATA_STEWARD) + workflow/DCR permissions.

Does the user need to be in the same group as the one that was originally assigned?
 
Yes. Reltio’s Workflow engine validates candidate group membership at the time of reassignment.
 

• If the user was not in the group at task creation time (e.g., SCH_DATA_STEWARD), If you attempt reassignment, you will get:

  "User does not have necessary permissions to become an assignee of the task..."

You’ve already observed this behavior with Luis.
 
Users must be in the same group as the candidate group defined when the task was created.
 

Is there a possibility of specifying which user should always be assigned (e.g., dummy user), then reassign based on responsibility?
 
Yes.
 
Option 1:  Use a Dummy Role and Dummy User
 

• Define a dummy role, like ROLE_DCR_ROUTER.
• Assign it only to your dummy user.
• Always set the groups variable to this role (ROLE_DCR_ROUTER) before creating the task.
• Initially, assign DCR tasks to this dummy user.
• Use external automation (like RIH) to:
  1. Inspect the changed attributes.
  2. Identify the correct group.
  3. Reassign to a user within that group (which must match the groups used at creation time or still be valid).

Option 2: Dynamically Set Candidate Group

• Modify BPMN to use ${groups} as you've done.
• Ensure that you set groups in the process start request before creating the task.
• This way, the candidate group aligns with the target reviewer group from the outset.

 
You can always assign to a dummy user, as long as that user and any reassignment target all belong to the group used at task creation time.
 
Using the documentation in https://docs.reltio.com/en/developer-resources/workflow-apis/workflow-apis-at-a-glance/workflow-api/start-a-process-instance (inhttps://docs.reltio.com/en/developer-resources/workflow-apis/workflow-apis-at-a-glance/workflow-api/start-a-process-instance), consider the following.
 
Endpoint
 

POST https://<workflow-host>/workflow-adapter/workflow/{tenantId}/processInstances

Template Payload (with groups variable)
 

{
  "processType": "dataChangeRequestReview",
  "businessKey": "changeRequests/2LJ44Jy",
  "objectURIs": [
    "changeRequests/2LJ44Jy",
    "entities/1Nx8TVM"
  ],
  "variables": {
    "groups": "SCH_LOCATION_REVIEWERS"
  } } 

•  processType must match the ID defined in your BPMN (dataChangeRequestReview).
• businessKey is typically the DCR URI.
• objectURIs must include the DCR and any related entity references.
• variables.groups is used by BPMN expressions.
• This variable must be set before the task is created.
• The group name (SCH_LOCATION_REVIEWERS) must match a role assigned to the user you want to assign or reassign the task to.