User Roles and Permissions Reference

DualEntry uses a role-based permission model to control what each user can see and do. You assign roles to users, and each role carries a set of permissions that govern access to records, actions, and system settings.

​

Managing roles

You manage roles and user assignments from Settings → Users & Roles. The roles list shows every built-in and custom role in your tenant, along with the number of users assigned to each. From this page you can create custom roles, assign roles to users, and view the permission details for any role. A user can hold more than one role, and their effective permissions are the union of every role they hold. Adding a narrow role to someone who already holds a broad one therefore widens nothing; removing access means removing the role that grants it. Roles apply across the whole organization rather than per entity; restricting someone to particular companies is a separate setting covered in Entity scoping. Role assignments are recorded in the audit trail with the roles held before and after the change, so you can answer who granted a permission and when. A user left with no roles at all keeps their login but is refused by every permission-guarded screen.

​

Built-in roles

DualEntry provisions fourteen system roles into every organization:

• Admin - full access to all records, actions, and system settings including tenant configuration, user management, and integrations. Admin bypasses permission checks rather than enumerating them.
• Controller - directs financial operations, budgeting, and internal controls. Can view and edit every record type and most configuration, but cannot create records or reach organization settings.
• Accountant - maintains records and prepares reports. Creates journal entries, intercompany journal entries, and bank transfers, and has read access across AP and AR documents.
• Accounts Payable - processes and verifies vendor invoices. Creates and edits bills, vendor payments, purchase orders, and the rest of the AP document set.
• Accounts Receivable - manages customer billing and collections. Creates and edits invoices, customer payments, sales orders, and the rest of the AR document set.
• View-Only - read-only access to financial records.
• View-Only Admin - read-only access to financial records, plus the ability to modify user permissions.
• IT - manages user permissions, integrations, and bank connections.
• Finance - reviews financial statements and reports, with view and edit access to key financial data.
• Operations - manages operational workflows including sales orders, customer interactions, and inventory.
• HR - manages HR system integrations and can view the chart of accounts.
• Warehouse Manager - oversees warehouse operations with view access to inventory and records.
• Warehouse Receiving Clerk - processes incoming inventory and creates item receipts.
• Warehouse Shipping Clerk - processes outgoing shipments and creates item fulfillments.

​

Custom roles

You create a custom role by cloning any built-in role and adjusting its permissions. For example, you might clone the Accountant role and remove the ability to post journal entries, creating a “Junior Accountant” role that can draft entries but must submit them for approval. Custom roles appear alongside built-in roles everywhere roles are selected, including the Roles picker used when issuing an API key, so a custom role is a practical way to scope an integration to exactly the record types it touches. Custom roles appear alongside built-in roles in the role list. You can edit a custom role’s permissions at any time; changes apply immediately to all users holding that role. When you edit a custom role, DualEntry logs the change in the audit trail with the previous and new permission sets, so you can track how roles evolve over time. You can also deactivate a custom role without deleting it, which prevents new assignments while preserving the role for historical reference.

​

Permission scopes

Each permission controls access to a specific action on a specific record type, and is written record:action, for example bill:edit. Four actions exist: You toggle each scope independently per record type when editing a role. For example, a role might have view and edit access to bills but not create or archive. Create, edit, and archive each imply view on the same record type, so a role granted bill:edit can also read bills. There is no separate approve or export scope: approval authority comes from workflow roles, and export follows the view permission on the record being exported.

​

Entity scoping

In a multi-entity setup, you can restrict a user to specific companies. Entity scoping is configured per user on the user detail page under Settings → Users & Roles: you mark the account as restricted and then list the companies it can reach. A user with no restriction sees every company in the organization. Scoping controls which companies a user reaches, not what they can do inside each one. Roles are organization-wide, so the same permissions apply in every company the user has access to. You cannot give someone the Accountant role in one entity and View-Only in another; if you need that, use two accounts or narrow the role itself. This lets you maintain a single user account across the tenant while keeping each person’s reach limited to the entities they work in. API keys work differently. A key has no entity scoping at all and reaches every company in the organization. A restriction you rely on for staff does not carry over to an integration authenticating with a key.

​

Permission matrix

The table below shows the default permissions for the six most-used system roles across core record types. Cells list the actions the role holds; All means view, create, edit, and archive. - = no access. Admin does not enumerate permissions; it short-circuits every check.

​

Workflow roles vs. user roles

Workflow roles and user roles serve different purposes. A user role controls your permissions: what you can see and do across the platform. A workflow role controls who can approve at a given stage in an approval workflow. A single user can hold several user roles (e.g., Controller and Accounts Payable) and several workflow roles (e.g., “VP Approver” and “Treasury Approver”). You manage workflow roles from Configuration → Company → User Roles. Workflow role assignments are independent of user roles, so you can grant approval authority to users regardless of their broader permission level. This separation lets you keep day-to-day permissions narrow while still involving the right people in approval chains. The practical consequence is that approval authority never shows up in the permission matrix above. Someone with View-Only can be a required approver on a payment run, and someone with Controller can hold no approval authority at all. Check both places when you are working out why a record is stuck.

​

API access

API keys carry roles of their own, chosen when the key is created. A key is not tied to the user who created it and does not inherit that user’s permissions or entity scoping, so it reaches every company in the organization. Assign the narrowest roles the integration needs, and note that a key holding Admin bypasses permission checks entirely. A key created with no roles authenticates but is refused by every endpoint. You create and manage API keys from Settings → Organization → Developer access → API Keys, and only the Admin role can open that tab. Revoking a key takes effect immediately and cannot be undone. An Admin can also change a key’s name and roles in place, which leaves the secret working. See How to Give an Integration Access to DualEntry. For details on how permissions interact with the audit trail, see audit trail and compliance.