Skip to main content
Approval workflows let you put a review step in front of high-impact spend actions before anything executes. Admins define the rules. When an action triggers a policy, it routes to the right approver automatically. If approved, Dash.fi fulfils the underlying operation — no manual follow-through needed.

​
What requires approval

Approval workflows apply across three areas:
  • Card requests — employees request a card with a name, spend limit, category restrictions, and cardholder. The policy determines whether it auto-approves or routes to a manager.
  • Bill payments — bills can be gated before payment is initiated.
  • Vendor management — creating a vendor, updating vendor details, and adding or changing vendor payment methods all support approval routing.

​
How routing works

Each action type has a policy attached to it. When a request is submitted, the policy evaluates it and one of three things happens:
  1. Auto-approved — the request meets the criteria and is fulfilled immediately, no human review needed
  2. Routed for review — an approval request is sent to the designated approver
  3. Auto-declined — the request fails the policy check and is rejected
Once a request is live, the system handles follow-up: automatic reminders go to approvers with pending requests, and escalations trigger if a request isn’t acted on within the configured window.

​
Request lifecycle

  • Draft — created but not yet sent to a decider
  • Submitted — in the approver’s queue, pending a decision
  • Approved — Dash.fi is executing the underlying operation
  • Declined — rejected; the action won’t proceed
  • Returned — sent back to the requester for revision; not a hard rejection
  • Fulfilled — the operation completed successfully

​
Where approvals surface

Approvers have a dedicated view showing only the requests assigned to them.

​
Bulk approve or decline from the Inbox

Approvers with a full queue can clear multiple requests at once from the desktop web Inbox → To review list. The bulk action bar works across every request type — card requests, bill payments, vendor changes, and expense submissions all sit in the same queue and can be actioned together.
  • Selection eligibility — only rows in Submitted status are selectable. Already-decided rows lock out of selection so you can’t re-decide them by accident.
  • Actions — the bar exposes Approve and Decline. Each button shows a count (for example, Approve 12) that reflects the number of eligible selected rows.
  • Confirmation — a dialog asks you to confirm before the batch runs. Approve fulfils the underlying operation on every request in the batch; Decline is terminal.
  • Result toast — after the batch finishes, Dash.fi shows an Approved N requests or Declined N requests toast. If any items fail — for example, another approver decided them first — a separate Failed to approve N requests toast reports the count that didn’t go through. Retry those individually.
Bulk decide uses the same Approval requests: write permission as deciding a single request, so approvers need no extra setup. The desktop web Inbox is the only place with bulk actions — the mobile Approvals inbox still handles requests one at a time.

​
Notes and collaboration

Any party can add notes to an approval request — useful for approvers to explain a decision or for submitters to add context upfront. Notes are visible to all parties involved and preserved in the audit trail.

​
Audit trail

Every approval request records when it was submitted, who submitted it, when a decision was made, who decided, and when fulfilment completed. The full history is available on each request.

​
Configuring policies

Approval policies are self-service — admins configure them in Company → Policy without any help from Dash.fi. See Policy Manager for a full guide to building and managing rules.

​
FAQ

Policies can route to a specific user, a user group, a role, or a structural role like a user group manager. This lets you mirror your org chart without hard-coding individual names.
Declined is terminal — the approver said no and the action won’t proceed. Returned sends the request back to the submitter for revision and resubmission. It’s not a hard rejection.
Yes. Policies can be configured to auto-approve requests that meet certain criteria — so low-risk or routine actions don’t create unnecessary friction.
Yes. Automatic reminders go out to approvers with requests sitting in their queue. Escalation triggers if a request isn’t actioned within the configured window.
Org admins configure policies themselves in Dash.fi. No involvement from Dash.fi’s team is required.