How to Configure Approval Workflows

Approval workflows in DualEntry enforce review gates before records can be posted. You define who needs to approve, under what conditions, and what happens when someone is unavailable.

​

Workflow setup and record types

You manage approval policies from Configuration → Company → Approval Policies. The list view shows every workflow in your tenant, with record types grouped into sections (Transactions, Money In, Money Out, Records, Revenue Recognition, and Other). From here you can create a new workflow, edit an existing one, or toggle a workflow between active and inactive states. Each workflow targets a single record type. DualEntry supports workflows on these record types: journal entry, intercompany journal entry, bank transfer, sales order, invoice, purchase order, bill, customer, vendor, contract, revenue recognition batch, fixed asset, and amortization. You create one or more workflows per record type, and each workflow can have its own conditions for when it applies.

​

Record-type-specific behavior

Fixed asset, amortization, and revenue recognition batch workflows have behavior worth calling out, because these records are driven by schedules rather than a single posting event. Fixed asset workflows route drafts and edits to a reviewer before they post. Because depreciation journal entries are generated from the asset’s schedule, changing the asset (for example, editing its depreciation method or life) is what triggers approval. The resulting journal entries inherit the approved schedule. If you also want a separate gate on the journal entries themselves, configure a journal_entry workflow alongside the fixed_asset one. Amortization workflows behave the same way. An amortization schedule drives its amortization journal entries, so editing the schedule sends it back for approval. This includes changes to the amortization method, start date, or the accounts it posts to. The generated entries inherit the approved schedule. Revenue recognition batches are gated as a single record type as well, though their workflows support a narrower set of conditions: amount, transaction currency, user, and role.

​

Defining stages and approvers

A workflow consists of one or more sequential stages. At each stage, one or more approvers must act before the record advances to the next stage. You assign approvers in three ways:

• Specific user - select an individual by name.
• Workflow role - assign a role (configured under user roles and permissions), and any user holding that role can approve.
• Manager of creator - DualEntry automatically routes to the record creator’s direct manager.

When all stages pass, the record’s approval status moves to approved and it becomes eligible for posting. If any stage is rejected, the record returns to the submitter for revision.

​

Segregation of duties

Segregation of duties is controlled per workflow through a self-approval setting, so review which workflows enforce it rather than assuming a global control. By default, a workflow allows self-approval: when the record’s creator is also an approver at a stage, DualEntry approves that stage on the creator’s behalf automatically. Disable self-approval on a workflow to enforce maker-checker separation for the record types it covers. When self-approval is disabled, DualEntry removes the record’s creator from the approver pool and routes the approval to the remaining eligible approvers, falling back to organization admins when a stage resolves only to the creator. If no approver other than the creator exists, the record cannot advance. The control fails closed instead of letting the creator approve. The creator is also blocked from approving at the API level, so the separation cannot be bypassed once it is enabled. A tenant with only one user has no second approver available, so workflows with self-approval disabled cannot complete there. For SOX scoping, confirm the setting on each workflow that gates a key control, since it applies per workflow rather than organization wide. Approval actions remain visible in the record’s audit trail either way.

​

Conditional routing

Conditional routing applies stricter review to higher-value or higher-risk records based on the conditions you define. You can route records to different workflows, or to different stages within a workflow, using:

• Amount thresholds - for example, bills over $10,000 require VP approval while those under $10,000 need only a manager.
• Company/entity - route based on which entity the record belongs to.
• Classification values - route based on department, project, or any other classification dimension.

When multiple workflows match a record, DualEntry applies the highest-priority workflow. You set priority order by dragging workflows in the list view.

​

Approver actions

An approval action carries one of four types:

• Approved - advances the record to the next step, or to approved if this is the final one.
• Rejected - returns the record with a rejection reason recorded against the action.
• Pending - the step is waiting on this approver.
• Auto approved - DualEntry cleared the step itself. Deactivating a policy auto-approves every record pending against it. Editing or deleting a policy auto-approves a pending record only if it no longer matches any applicable workflow; otherwise the record is resubmitted for approval under the new policy.

A step declares whether it needs Require all or Require any of its approvers, so you model a committee that must agree unanimously and a rota where whoever gets there first can clear it, using the same building block. There is no delegate action and no request-changes action. An approver who cannot act has to be replaced on the policy rather than handing their queue to someone else for a week. Plan coverage by naming more than one approver on a step and setting it to Require any, rather than by expecting a vacation handoff. Rejection is the mechanism for sending something back. Because the reason is stored on the action, a rejection reads in the history as the specific objection rather than as a bare status change.

​

Audit trail

Every approval action is logged permanently and in full. DualEntry records each approval and rejection with the acting user, the timestamp, the action type, and the rejection reason where one applies. The history reads the way an auditor would expect to see it. This audit trail is immutable and accessible from the record’s history tab or from the global audit trail. Automatic actions are captured too. When a policy change, deactivation, or deletion auto-approves a record that was pending, DualEntry writes that event to the history along with its reason. Each entry retains the step name, step order, and policy version that were in effect at the time of the action. This holds even if the policy is later edited or deleted, so the record’s history remains accurate for auditors.

​

API access

The API exposes endpoints for programmatic access to approval data. Use /public/v2/workflows/execution-states/ to track where a record sits in its workflow, /public/v2/workflows/actions/ for the full action history, and /public/v2/workflows/roles/ for managing workflow roles. The /public/v2/workflows/ endpoint lets you list and filter workflows by company_id, record_type, and is_active. You can integrate this into external systems to programmatically check which workflows are active or to build custom dashboards that surface pending approvals across your organization. Approval workflows apply to records created through the API or an integration, not only to records entered manually. No record type bypasses workflow enforcement based on how it was created: a bill created through /public/v2/bills/ enters the same workflow as one entered in the UI. For details on how approval actions interact with the broader permission model, see user roles and permissions.