How to Assign the Six Default Roles in DAVE

A role in DAVE is a named set of permissions. When you assign a role to a user, you grant them every permission that role contains. When you remove a role, those permissions are revoked on the user's next login. Roles are the mechanism through which DAVE enforces access control across all 20 permission types, at both the API layer and the frontend.

DAVE ships with six default roles: Admin, Create, Curate, Use, Reporting, and Financial. These are editable database rows, not hardcoded values, so your organisation can modify them as responsibilities evolve. The six defaults are a well-considered starting point that covers the distinct responsibilities in a typical AI workflow operation: platform governance, agent building, workflow design, operational execution, oversight, and commercial management.

A user with no roles assigned sees an empty dashboard and cannot perform any meaningful action in the platform. A user with the wrong roles may be blocked from work they need to do, or may have access to parts of the platform they should not. Getting role assignment right is the foundation of DAVE's access control model.

Permissions are enforced server-side on every request. There is no UI-only permission: if a user does not have the required permission token for an action, the API will refuse the request regardless of how it was initiated, whether through the browser, the REST API, or an MCP tool connection. This means role assignment is a real security control, not just a UI convenience.

Each of DAVE's six default roles is designed for a distinct function. Here is what each one grants and who it is for.

• Admin. Grants admin:*: full access to all admin screens and settings. This includes User Management, Settings, Providers, Feature Flags, and every other admin function. The Admin role is for the people accountable for the platform's configuration, security posture, and operational integrity. It should be held by the smallest number of people who genuinely need it, typically two or three, to avoid a single point of failure without creating an ungoverned pool of administrators. An Admin can grant and revoke any role, including Admin itself, on any user in the tenant.

• Create. Grants agents:read and agents:write: the ability to create and edit agents. Agents are the AI-powered components that hold prompts, provider connections, and behavioural logic. The Create role is for AI engineers, technical product managers, and senior analysts who build and maintain the agents that power workflows. Create role holders do not automatically have workflow-building access: that requires the Curate role.

• Curate. Grants workflows:read, workflows:write, and agents:read: the ability to build and modify workflows, and to read (but not edit) agent configurations. The Curate role is for business analysts, operations leads, and process designers who assemble agents and logic into complete workflows. The inclusion of agents:read without agents:write is a deliberate separation: workflow designers can use agents without being able to change their underlying behaviour.

• Use. Grants instances:*, tasks:*, and artifacts:read: the ability to run workflow instances, complete assigned tasks, and read workflow artifacts. The Use role is for every team member who interacts with AI workflows as part of their daily work. It is typically the most widely held role in a tenant. Only users with the Use role can be assigned tasks.

• Reporting. Grants reports:read and audit:read: read-only access to reports and audit logs. The Reporting role is for compliance officers, data protection officers, and managers who need operational visibility without the ability to build or run workflows. The role is intentionally read-only: oversight does not require the ability to change what is being overseen.

• Financial. Covers commercial and financial oversight of the tenant. Assign to the team members responsible for billing and commercial management. The specific permission tokens for this role are not listed in the current help documentation available at the time of writing: see the gap note in the report accompanying this guide.

A single user can hold multiple roles simultaneously. Role permissions are additive: a user with both Create and Curate has all the permissions of each role combined. There is no conflict resolution needed because the roles are designed to be complementary rather than overlapping.

Common role combinations and when to use them:

• Create and Curate. For a senior AI engineer or technical lead who both builds agents and designs the workflows that use them. This combination gives full read-write access to both agents and workflows. Use it for people who own an end-to-end AI capability, from the agent prompt to the workflow logic.

• Curate and Use. For a business analyst or operations lead who designs workflows and also runs them in production. This combination is appropriate when the same person is responsible for both the design and the day-to-day operation of a workflow. It is the most common combination for teams in early AI workflow adoption where roles have not yet fully separated.

• Use and Reporting. For a team lead or senior operator who runs workflow instances and also needs visibility into reports and audit logs for their area. This combination gives operational access without the ability to modify workflows or agents.

• Admin only. For a dedicated platform administrator whose job is governance, not production use. An Admin-only account has no workflow or agent access: the Admin role grants administrative permissions, not operational ones. A platform administrator who also needs to run workflows should hold Admin and Use.

Avoid assigning the Admin role alongside operational roles (Create, Curate, Use) unless the person genuinely needs both. An Admin who is also the primary workflow builder cannot objectively review the workflows they built, and an Admin who runs workflow instances has no separation between the person who configured the system and the person who operates it. These separations exist for the same reason they exist in financial controls and software deployment pipelines.

DAVE's access control model is built on 20 permission types. Each permission type controls a specific category of action, such as reading agents, writing workflows, running instances, or reading audit logs. Roles are collections of these permission types: the Admin role bundles all of them under admin:*, while narrower roles grant only the specific permission types their function requires.

Enforcement happens at two layers:

1. API layer. Every REST API request is checked against the requesting user's permission set before the action is executed. A request that lacks the required permission token is refused with a 403 response, regardless of how it was made. This applies to requests from the browser, from direct API clients, and from MCP tool connections. There is no way to bypass API-layer enforcement from the client side.

2. Frontend layer. The UI hides or disables controls that the current user does not have permission to use. This is a usability layer: it prevents users from encountering confusing error messages for actions they are not permitted to take. It is not the primary enforcement layer. The API layer is the authoritative control.

The practical implication is that role assignment is a genuine security control, not just a UI configuration. Assigning the wrong role to a user does not just change what they see in the browser: it changes what they can do through every access path the platform supports. Conversely, removing a role from a user revokes those permissions across all access paths on their next login, including any MCP tool connections they have configured.

When auditing access control for a compliance review, the role assignments in User Management are the authoritative record of who has which permissions. The audit log records every role change, including who made the change and when, so the history of permission grants and revocations is fully traceable.

How many roles can a single user hold?
There is no documented limit on the number of roles a single user can hold. In practice, most users hold one to three roles. The minimum-necessary-roles principle applies: assign only the roles a user needs for their specific responsibilities.

What does a user see if they have no roles?
A user with no roles assigned sees an empty dashboard and cannot perform any meaningful action in the platform. If a new user reports seeing an empty screen after their first login, check their role assignment in User Management and assign the appropriate roles, then ask them to log out and back in.

Do role changes take effect immediately?
Role changes are saved immediately when you click Save, but they take effect on the user's next login. A user who is currently logged in will continue to use their old permissions until they log out and back in. If the new roles need to apply immediately, ask the user to log out.

Can I create custom roles beyond the six defaults?
The six default roles are editable database rows, so the role model can be extended. The specific process for creating custom roles is not covered in the User Management help documentation. Contact DAVE support at hellodave.ai or refer to the Settings documentation for role configuration options.

What is the difference between inactive and suspended?
Both inactive and suspended accounts cannot log in. The distinction is administrative: inactive typically indicates a deliberate deactivation (for example, an employee who has left), while suspended may indicate a temporary hold pending investigation. Both statuses preserve the account and its audit history. Use the Status dropdown in edit mode to set either state.

Can an Admin remove their own Admin role?
The help documentation does not specify whether self-demotion is blocked. As a precaution, always ensure at least one other Admin account exists in the tenant before making changes to your own role assignment. If you accidentally remove your own Admin role, another Admin can restore it.

What are the specific permissions for the Financial role?
The specific permission tokens for the Financial role are not listed in the current help documentation. The role covers commercial and financial oversight of the tenant. For details on what the Financial role grants, contact DAVE support at hellodave.ai.