Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt

Use this file to discover all available pages before exploring further.

​
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. Each user receives exactly one user role per entity, and the role determines the full set of actions available to that user within that entity’s scope.

​
Built-In Roles

DualEntry ships with six built-in roles:
  • Admin - full access to all records, actions, and system settings including tenant configuration, user management, and integrations.
  • Controller - full accounting access (all record types, all actions) but no access to system-level settings like user management or tenant configuration.
  • Accountant - day-to-day transaction entry, posting, and reporting. Can create and edit bills, invoices, journal entries, and run reports. Cannot modify system settings or manage users.
  • Viewer - read-only access to all reports and records. Cannot create, edit, or approve anything.
  • AP Clerk - scoped to accounts payable: bills, vendor payments, and purchase orders. Can create, edit, and submit for approval. No access to AR, GL journal entries, or system settings.
  • AR Clerk - scoped to accounts receivable: invoices, customer payments, and sales orders. Can create, edit, and submit for approval. No access to AP, GL journal entries, or system settings.

​
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 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. The available scopes are:
ScopeDescription
CreateCreate new records of this type
ReadView records and their details
UpdateEdit existing records
DeleteDelete or void records
ApproveAct as an approver in workflows
ExportExport records and reports to CSV/Excel
You toggle each scope independently per record type when editing a role. For example, a role might have create, read, and update access to bills but not delete or approve.

​
Entity Scoping

In a multi-entity setup, you can scope permissions to specific companies. A user might have the Accountant role for Entity A (full day-to-day access) and the Viewer role for Entity B (read-only). Entity scoping is configured per user on the user detail page under Settings → Users & Roles. This lets you maintain a single user account across the tenant while controlling exactly what each person can do in each entity.

​
Permission Matrix

The table below shows the default permissions for each built-in role across core record types.
Record TypeAdminControllerAccountantViewerAP ClerkAR Clerk
BillsAllAllCRUDReadCRUD-
InvoicesAllAllCRUDRead-CRUD
Journal EntriesAllAllCRUDRead--
Purchase OrdersAllAllCRUDReadCRUD-
Sales OrdersAllAllCRUDRead-CRUD
Bank TransfersAllAllCRUDRead--
ReportsAllAllRead, ExportReadReadRead
System SettingsAll-----
All = create, read, update, delete, approve, export. CRUD = create, read, update, delete. - = no access.
The Approve scope is included in “All” but not in “CRUD.” Clerks and Accountants can submit records for approval but cannot act as approvers unless explicitly granted the Approve scope.

​
Workflow Roles vs. User Roles

Workflow roles and user roles serve different purposes. A user role controls what you can see and do across the platform-your permissions. A workflow role controls who can approve at a given stage in an approval workflow. A single user can hold one user role (e.g., Controller) and multiple workflow roles (e.g., “VP Approver” and “Treasury Approver”). You manage workflow roles from Settings → Approval Workflows → 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.

​
API Access

API tokens inherit the permissions of the user who created them. If a Viewer creates an API token, that token has read-only access. If an Admin creates a token, it has full access. Scope API tokens to the minimum permissions needed for the integration to follow the principle of least privilege. You create and manage API tokens from Settings → Users & Roles → API Tokens. Each token is tied to the creating user and inherits that user’s entity scoping as well. You can revoke a token at any time, and revocation takes effect immediately across all active sessions using that token. For details on how permissions interact with the audit trail, see audit trail and compliance.
Last modified on May 28, 2026