Join the Waitlist
Guide

How to Assign a Task to a Role Instead of a Person

By DAVE by voolama5 stepsUpdated AUG 2026AI

Summary

When a workflow task is assigned to a role rather than a named individual, any user holding that role can claim and complete it. This guide explains when to use role-based assignment, how it works in practice, and how to configure your workflow nodes to use it.

The steps

  1. Understand how task assignment works in DAVE

    In DAVE, tasks are generated by workflow instances when execution reaches an interaction or review node. The Assignee field on each task shows which user is responsible for completing it. When a task has no assignee, it appears in the Task Inbox with a dash in the Assignee column, meaning it has not yet been claimed.

    Task assignment is controlled by the configuration of the node in the workflow graph that generates the task. The workflow engine reads that configuration when the instance reaches the node and sets the assignee accordingly. To assign a task to a role rather than a named person, you configure the node to target a role, not a specific user ID.

    Do this
    • Open Tasks in the sidebar to view the Task Inbox and familiarise yourself with the Assignee column.
    • Note which tasks show a user ID in the Assignee column and which show a dash: the dash indicates an unclaimed task.
    • Identify the workflow and node that generates the task you want to reassign to a role.
    Example

    A contract review workflow generates a human_review task every time a new contract is submitted. Currently the node is configured to assign the task to a single senior lawyer by user ID. When that lawyer is unavailable, tasks accumulate. Switching the assignment to the Legal Review role means any member of the legal team can claim and complete the task.

    Best practice

    Before changing assignment configuration, confirm which users hold the target role. Go to Admin, then Settings, then Users and Roles to check role membership. Roles with no active members will leave tasks unclaimed: always ensure at least one active user holds the role before routing tasks to it.

  2. Open the workflow in the Workflow Editor

    Workflow node configuration, including task assignment, is set in the Workflow Editor. You need the Curate role to edit workflows. If you only have the Use role, you can complete tasks but cannot change how they are assigned: ask a user with the Curate role to make the change.

    Navigate to Workflows in the sidebar, find the workflow that contains the node you want to reconfigure, and open it. Then open the Workflow Editor for that workflow to access the node configuration.

    Do this
    • Navigate to Workflows in the sidebar.
    • Locate the workflow containing the task-generating node. Use the workflow name or description to identify it.
    • Open the workflow and then open the Workflow Editor.
    • Confirm you have the Curate role: if the editor is read-only or you cannot save changes, contact your Admin to verify your role assignment at Admin, then Settings, then Users and Roles.
    Example

    The contract review workflow is listed in the Workflows page. Opening it and clicking into the Workflow Editor shows the graph with all nodes and edges on the canvas.

    Best practice

    Before editing a live workflow, check whether any instances are currently running. Changes to node configuration take effect on new instances, not on instances already in progress. If the workflow is actively used in production, consider duplicating it and testing the role-assignment change on the copy before applying it to the original.

  3. Select the interaction or review node that generates the task

    In the Workflow Editor, tasks are generated by four node types: User Interaction, Human Review, Agent Review, and Safety nodes. Each of these node types produces a task when the workflow instance reaches it. Click the node in the canvas to select it and open its configuration in the right-hand properties panel.

    The properties panel shows the node's current configuration, including its assignment settings. This is where you change the assignment from a named user to a role.

    Do this
    • In the Workflow Editor canvas, locate the node that generates the task you want to reassign. It will be one of: User Interaction, Human Review, Agent Review, or Safety.
    • Click the node to select it. The right-hand properties panel opens with the node's current configuration.
    • Review the current assignment setting. If it shows a specific user, this is what you will change to a role.
    Example

    In the contract review workflow, the Human Review node is the step that generates the review task. Clicking it in the canvas opens its properties on the right, showing the current assignee as a specific user ID.

    Best practice

    If you are unsure which node generates the task you want to reassign, cross-reference the task type shown in the Task Inbox. A human_review task is generated by a Human Review node; a user_interaction task is generated by a User Interaction node. Do not confuse Agent Interaction nodes, which run an AI agent automatically with no human task, with Agent Review nodes, which generate a task for a human to review agent output.

  4. Set the assignment to a role

    In the node's properties panel, change the assignment configuration from a named user to a role. When the assignment targets a role, the workflow engine does not assign the task to a specific user ID at the moment the task is created. Instead, the task appears in the Task Inbox as unclaimed (Assignee shown as a dash) and is visible to all users who hold that role.

    The first user holding the role to open the task claims it. Once claimed, the task's Assignee field updates to that user's ID, and the task moves to in_progress status. Other users with the same role can still see the task in the Task Inbox but it is now owned by the user who claimed it first.

    Save the workflow after making the change. The updated assignment configuration takes effect on all new instances created after the save. Existing in-progress instances continue to use the previous configuration.

    Do this
    • In the node's properties panel, locate the assignment or assignee field.
    • Change the assignment from the named user to the target role. Select the role from the available options.
    • Save the workflow. Confirm the save succeeded before closing the editor.
    • Test the change by running a new instance of the workflow and confirming the generated task appears in the Task Inbox as unclaimed, visible to users holding the target role.
    Example

    After changing the Human Review node's assignment from the named lawyer's user ID to the Legal Review role, the next contract submitted generates a human_review task with no specific assignee. Any member of the legal team sees it in their Task Inbox. The first lawyer to open the task claims it and completes the review.

    Best practice

    After saving, verify the change by checking the Task Inbox after the next instance runs. The Assignee column should show a dash until a user with the role opens the task. Communicate the change to the team holding the role: they need to know to check the Task Inbox for unclaimed tasks, not just tasks assigned directly to them. If the task has a due date configured, role-assigned tasks are subject to the same timeout rules as user-assigned tasks. Ensure the team monitors the Task Inbox regularly so tasks do not time out before being claimed.

  5. Verify the assignment in the Task Inbox

    After the workflow change is saved and a new instance has run, confirm the role-based assignment is working correctly by checking the Task Inbox.

    Navigate to Tasks in the sidebar. Set the status filter to pending to show only tasks awaiting action. Find the task generated by the updated workflow. The Assignee column should show a dash, confirming the task is unclaimed and available to any user holding the target role.

    Ask a user who holds the target role to open the task and confirm it appears in their inbox and moves to in_progress when they open it. Confirm the Assignee field updates to that user's ID after they claim the task.

    Do this
    • Navigate to Tasks in the sidebar.
    • Set the status filter to pending.
    • Locate the task from the updated workflow. Confirm the Assignee column shows a dash.
    • Ask a user holding the target role to open the task and confirm it appears in their inbox and moves to in_progress when they open it.
    • Confirm the Assignee field updates to that user's ID after they claim the task.
    Example

    After the contract review workflow is updated, the next submitted contract generates a pending human_review task with no assignee. A member of the legal team opens the task, and the Assignee field updates to their user ID. The task status changes from pending to in_progress. Other legal team members can still see the task in their Task Inbox but it is now owned by the user who opened it first.

    Best practice

    If the task does not appear in the Task Inbox for users holding the target role, check that those users actually hold the role at Admin, then Settings, then Users and Roles. If the Assignee column shows a specific user ID rather than a dash, the node configuration may still be targeting a named user: return to the Workflow Editor and confirm the save was successful. Use the status filter regularly to monitor unclaimed tasks. A growing list of unclaimed pending tasks is a signal that the role has insufficient active members to handle the current volume.

What role-based task assignment is and when to use it

In DAVE, every task has an Assignee: the user responsible for completing it. By default, a workflow node can be configured to assign its task to a specific named user. This works well for stable, low-volume processes where one person always owns a step. It creates a bottleneck the moment that person is unavailable, changes roles, or the process scales beyond one person's capacity.

Role-based assignment solves this by targeting a role rather than a user. When a task is assigned to a role, it appears in the Task Inbox as unclaimed and is visible to every user who holds that role. The first person to open the task claims it. This is the first-to-claim model: there is no queue manager, no dispatcher, and no manual reassignment step. The team self-organises around the available work.

Use role-based assignment when:

  • Multiple people share responsibility for a type of review and any one of them is qualified to complete it.
  • The person who owns a step changes frequently, due to rotation, leave, or team growth.
  • You want to increase throughput by allowing parallel claiming across a team rather than serialising tasks through one person.
  • You are building a workflow for a team that does not yet have a fixed owner for a step.

Use named-user assignment when a specific individual must be the one to review or approve: for example, when a particular signatory is required for a contract, or when a compliance rule requires a named approver.

How tasks reach the Task Inbox

Tasks are generated automatically by the workflow engine when a running instance reaches an interaction or review node. The four node types that generate tasks are: User Interaction, Human Review, Agent Review, and Safety. Each produces a task of the corresponding type: user_interaction, human_review, agent_review, or safety_check.

When the task is created, the workflow engine reads the node's assignment configuration and sets the Assignee field. If the configuration targets a named user, the Assignee is set to that user's ID immediately. If the configuration targets a role, the Assignee is left unset, shown as a dash in the Task Inbox, and the task is made visible to all users holding that role.

The Task Inbox is accessible from Tasks in the sidebar. It is available to users with the Admin or Use role. Users with other roles, including Create, Curate, Reporting, and Financial, do not have access to the Task Inbox and cannot complete tasks. When planning role-based assignment, ensure the target role is one that includes task access. In practice this means routing tasks to the Use role or a custom role with equivalent task permissions.

Pending tasks block workflow progress. The instance waits at the node that generated the task until an assignee submits a decision. A growing queue of pending tasks is a direct signal that workflow throughput is constrained by human review capacity.

Roles and permissions: who can see and complete tasks

DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by the tenant's Admin. Task access is restricted to the Admin and Use roles: only users holding one of these roles can view the Task Inbox, open task details, and submit decisions.

This has a direct implication for role-based task assignment. If you assign a task to a role whose members do not have task access, for example the Curate or Reporting role, those users will not see the task in their Task Inbox and the task will remain unclaimed. Before configuring role-based assignment, verify that the target role has task access.

The safest approach is to assign tasks to the Use role or to a custom role that has been given task permissions explicitly. If your organisation uses custom roles, confirm with your Admin that the custom role includes the permissions required to view and complete tasks. Role membership is managed at Admin, then Settings, then Users and Roles. A user can hold multiple roles simultaneously, so a user who needs both to build workflows (Curate) and to complete tasks (Use) can hold both roles at once.

Monitoring and managing role-assigned tasks

Role-based assignment distributes task ownership across a team, which improves resilience but requires active monitoring. Unlike named-user assignment, where the assignee receives a direct notification and knows the task is theirs, role-based assignment relies on team members checking the Task Inbox for unclaimed work.

The Task Inbox status filter is the primary monitoring tool. Filter to pending to see all tasks awaiting action, including unclaimed role-assigned tasks shown with a dash in the Assignee column. A high count of pending tasks with no assignee is a signal that the team is not checking the inbox frequently enough, or that the role has too few active members for the current task volume.

Due dates add urgency. If a task has a due date configured in the workflow node, it is displayed in the Due column of the Task Inbox. Tasks approaching their due date should be prioritised. If a task times out before being claimed, it moves to failed status and the parent instance may stall or take an error path depending on the workflow's configuration.

Every task decision is recorded in the audit log: the acting user, the decision (Approve, Reject, or Request Changes), the timestamp, and any comment the reviewer attached. This audit trail is available regardless of whether the task was assigned to a named user or a role. When SOC 2 or GDPR compliance modes are active, task completion events support SOC 2 CC6.1 and GDPR Article 30 requirements.

Frequently asked questions

Can two users complete the same task simultaneously?
No. Once a user opens a role-assigned task, it moves to in_progress and the Assignee field updates to that user's ID. Other users holding the role can still see the task in their Task Inbox, but the task is now owned by the user who claimed it. Only the claiming user or an Admin can submit the decision.

What happens if nobody claims the task before the due date?
If the task has a due date and it is not completed in time, the task may move to failed status. The parent workflow instance will stall or follow an error path depending on how the workflow is configured. Monitor the Task Inbox regularly and ensure the team holding the role knows to check for unclaimed pending tasks.

Does role-based assignment send a notification to role members?
Notification behaviour depends on your tenant's notification configuration in Admin, then Settings, then Notifications. If the Task Assigned event is configured to notify the task assignee and the task has no named assignee, notification routing depends on how your Admin has configured the audience for that event. Check your notification settings and confirm the expected behaviour with your Admin.

Which roles can complete tasks?
The Task Inbox is accessible to users with the Admin or Use role. Users with the Create, Curate, Reporting, or Financial role cannot access the Task Inbox. If you are routing tasks to a custom role, confirm with your Admin that the role has task permissions enabled.

Can I see who claimed a role-assigned task after the fact?
Yes. The task detail page shows the current Assignee. The audit log records all task assignment changes and task completion events with the acting user's identity and a timestamp. This audit trail is available to Admin users and supports compliance reporting when SOC 2 or GDPR modes are active.

How to Assign a Task to a Role in DAVE Workflows