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 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. Bulk actions are also available in the mobile app’s Inbox tab: long-press a request in To review to start a selection, then approve or decline up to 20 requests per batch. See Approvals on mobile.

​
Deciding expenses from the Expenses table

Expense approvals don’t have to go through the Inbox. Approvers can decide submitted expenses directly on the Expenses → Card Spend table:
  • From the expense sheet — open a submitted expense you’re assigned to review and use the Approve and Decline buttons at the bottom of the sheet. A dialog asks you to confirm before the decision runs.
  • In bulk — select submitted expenses in the table and use Approve or Decline in the bulk action bar. The buttons show a count of the selected expenses awaiting your decision, and the confirmation dialog calls out any selected rows that aren’t decidable and will be skipped.
Both paths use the same Approval requests: write permission as deciding from the Inbox. See Submitting expenses for the full walkthrough.

​
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.