How the assignee list is calculated for a task in a DCR

Question

How the assignee list is calculated for a task in a DCR

Answer

The calculation of the assignee list for a task in a Data Change Request Task (DCRT) involves several steps:

1. Retrieve Candidate Groups: The process begins by retrieving the candidateGroups configured for the task. These groups map to roles in Reltio terms. Users who belong to these groups are considered potential assignees.

2. Admin Users: The system retrieves admin users and tenant admin users. These users are considered potential assignees.

3. Intersection of Users: The system finds the intersection of users across the candidate groups and admin users to determine potential assignees.

4. Access Types: The task may have specific access types configured (e.g., READ, DELETE, ACCEPT_CHANGE_REQUEST). The system retrieves all roles for the entities for these access types and finds users who have all the required permissions on the objects involved in the task.

5. Union of Users: The final list of possible assignees is the union of users from the intersection of candidate groups and admin users, and users with the required access types.

6. Task Assignment: The system uses a listener class (TaskStartEventListener) to find the least-used user(s) from the possible assignees and assigns the task to one of them. This is determined by computing the number of tasks assigned to each user and selecting the user with the fewest tasks.

This process ensures that tasks are assigned to users with the necessary roles and permissions, while balancing the workload among potential assignees.

How the workflow UI determines which users appear in the Assignee dropdown for a given task.

The UI identifies the task and its impacted objects (objectURIs) via GET /tasks/{taskId}.

It then asks the platform for eligible assignees using POST /assignee for that same taskId.

A user will appear only if both are true:

• They hold at least one role that is listed in the task’s candidateGroups (from the BPMN user task definition), and
• They have the required object permissions on all objects referenced by the task’s objectURIs.

For DCR review/approval tasks, the required permissions depend on the tenant setting applyDcrWithoutPermissions:

• false (default)The user must have ACCEPT_CHANGE_REQUEST and object‑level rights CREATE/READ/UPDATE/DELETE/MERGE on the impacted objects.
• true: user needs READ + ACCEPT_CHANGE_REQUEST.

Endpoints to consider during an investigation

• Identify the task and objects,

   

  GET {workflowPath}/workflow/{tenantId}/tasks/{taskId}

   

  Returns the task metadata, including objectURIs (entities/DCRs/relations touched by the task).

• Compute eligible assignees for that task

   

  POST {workflowPath}/workflow/{tenantId}/assignee
  Body: { "taskId": "<taskId>" }

   

   

  Returns the exact list shown by the UI for the Assignee picker.

• Inspect BPMN user task configuration (candidate groups)

   

  GET {workflowPath}/workflow/{tenantId}/processDefinitions/{processType}

   

  Look for userTask → activiti:candidateGroups="…".

• Resolve object‑level rights for concrete objects

   

  POST {env}/reltio/permissions/{tenant}/_getAccessRoles
  Body: { "objectURIs": [ "<uri1>", "<uri2>", … ] }

   

  Use this to check who has READ/UPDATE/MERGE (and other CRUD/MERGE rights) on the actual objects referenced by the task.

   

  Why _getAccessRoles? 

  Eligibility depends on the real objects and your metadata/role security. _getAccessRoles evaluates rights against the specific objectURIs in the task.

  Eligibility Logic (what /assignee checks)

  A user appears in /assignee for a given taskId only if both conditions are true:

  1. Role Gate: The user has ≥ 1 role contained in the task’s candidateGroups.
  2. Object Rights Gate: The user has the required permissions on all objectURIs touched by the task.

  DCR Review/Approval — Required Permissions

  Note: If a candidate user fails either gate, they are not returned by /assignee.

  Tenant Setting applyDcrWithoutPermissions	Minimum Rights Required on all impacted objects
  false (default)	ACCEPT_CHANGE_REQUEST and CREATE/READ/UPDATE/DELETE/MERGE
  true	READ and ACCEPT_CHANGE_REQUEST

   

  How Object Permissions Are Evaluated

  • Rights are checked against the concrete objectURIs (e.g., the referenced HCP/HCO records, addresses, relations, nested attributes/sources) involved in the task.
  • Metadata/role security can cause two DCRs with the same structure to yield different eligible assignee counts because the affected objects fall into different security slices.

  Use POST /reltio/permissions/{tenant}/_getAccessRoles to confirm who has READ/UPDATE/MERGE on those specific objectURIs.

Example: Why One DCR Shows 3 Assignees and Another ~30

Assume two DCRs (A and B) in the same workflow step; therefore, the same BPMN candidate groups apply.

Bottom line: The difference is by design and driven by object‑level permissions on the specific values/objects touched by each DCR.

FAQ

Q: Why does the UI show fewer assignees than expected?

Most often, candidates fail the object rights gate for the specific objectURIs in that task.

Q: Can I bypass object rights for DCR application?

Only if your tenant has applyDcrWithoutPermissions=true. Then READ + ACCEPT_CHANGE_REQUEST suffices; otherwise full CRUD/MERGE is required.

Q: Is /assignee the source of truth for the UI list?

Yes. The UI displays exactly what POST /assignee returns for the taskId.