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 - choose 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 by the Enforce separation of duties toggle, so review which workflows enforce it rather than assuming a global control. The toggle is off by default, which 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. Turn the toggle on to enforce maker-checker separation for the record types the workflow covers. When separation of duties is on, DualEntry removes the record’s creator from the approver pool and routes the approval to the remaining eligible approvers. When a stage resolves only to the creator, DualEntry falls back to organization admins. 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 separation of duties on cannot complete there. For SOX scoping, confirm the toggle 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. With separation of duties on, approvers also cannot edit a record while it waits on approval. See editing records during approval review.

​

Turn on separation of duties

To enforce segregation of duties on an approval workflow:

1. Navigate to Configuration → Company → Approval Policies.
2. Open the workflow you want to change, or create a new one.
3. Turn on Enforce separation of duties.
4. Save the workflow.

After you save, the creator of each new record the workflow covers cannot approve it, and approvers on the workflow cannot edit it while it awaits approval. Saving a policy change also resubmits records already pending against the workflow, as described in approver actions.

​

Editing records during approval review

When someone edits a record that is awaiting approval, DualEntry saves the change and keeps the record at its current step. The workflow does not restart. Who can make that edit, and what happens after, depends on the workflow’s Enforce separation of duties toggle. Separation of duties on: DualEntry blocks any approver on the workflow from editing the record while it awaits approval. This covers approvers on every step, not only the current one, and applies to admins too. The save fails with the message “Segregation of duties is enabled on this approval policy. An approver cannot edit a record that is awaiting approval. Reject it instead.” An approver who wants changes should reject the record, which returns it to the submitter for revision. The creator can still edit their own record, and users who are not approvers on the workflow can edit it if their role allows. Either way, the record stays at its current step and the original creator stays the record’s creator, so the creator still cannot approve it. Separation of duties off: Approvers whose role can edit the record type can change it during review. If the editor is an approver on the current step, DualEntry treats them as the record’s creator and approves their step automatically. On a single-step workflow, the edit alone approves and posts the record. Edits to records that are already approved and posted follow a separate path. The Re-approval Triggers on the approval policy’s Settings tab set which field changes move a posted record back to Draft and restart its approval. If no triggers are configured for the record type, any edit to a posted record restarts approval.

​

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.

​

Troubleshooting

These errors come from separation of duties being on for a workflow. “Segregation of duties is enabled on this approval policy. An approver cannot edit a record that is awaiting approval. Reject it instead.” You are an approver on the record’s workflow, so you cannot change the record during review. Reject the record with a reason so the submitter can make the change and resubmit. “Segregation of duties is enabled on this approval policy. The creator of a record cannot approve it” You created the record, so another approver on the step has to approve it. This can happen when separation of duties was turned on after the record was submitted. “Segregation of duties is enabled but no admin users (other than the creator) exist in the organization to replace the creator as approver for step ‘Step 1’.” The step named in the message resolves only to the record’s creator, and no other admin is available to take it over. Add another approver to the step, or invite a second admin to the organization.

​

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.