Add an approval step
Pause a workflow until an Owner, Admin or Manager approves or rejects it in Assignar Pay, then continue on the matching path
Some steps should not run without a person saying yes: a large purchase order, a long shift, a supplier invoice over a limit. The Assignar Pay Request Approval in Assignar action pauses the workflow and sends a request to Connect → Approvals. When someone you named approves or rejects it, the workflow carries on down the matching path, and Assignar Pay keeps a lasting record of who decided, when, and why.
The people deciding do not need the builder. Decide approvals covers their side.
Add the step
- Build and test the trigger and any lookups first, so the approval step already knows what is being decided.
- Where the workflow should wait, add an action, search for Assignar Pay and choose Request Approval in Assignar.
- Fill in what the approver will see:
- Title: the line in the Approvals list and in the approver's notification. Make it specific, such as Invoice INV-7 to Harbourside Developments — $48,250, using the data selector so each run fills in its own details.
- Details (optional): what to check and why.
- Choose who can decide, with Approver Roles, Approver Users or both. Roles are Owner, Admin and Manager; everyone who holds the role when the request is decided can answer. Prefer roles for day-to-day work, because people go on leave and roles do not.
- Link the record being decided with Linked Record Type and Linked Record ID: an invoice, timesheet, docket, workpack, quote, project or client. Approvers get a link to it, and the decision is also written to that record's activity.
- Optionally add an Amount and Currency, which show in the list and can be sorted on, and Context: up to 20 label-and-value pairs, such as the supplier and the project, shown on the request.
- Set Expires In (Hours), from 1 to 720 (30 days). If nobody decides in time, the request is marked Expired, within the hour after the deadline, and the workflow continues.
- After the step, add a branch on its result (below).
- Test the flow. The test raises a real request: open Approvals, decide it, and check the workflow takes the right path. Then publish.
Each approver gets a notification that links to the request, and the Approvals badge counts it for them.
Branch on the answer
The step returns:
| Field | What it holds |
|---|---|
| Approved | Yes or no |
| Outcome | Approved, rejected or expired |
| Comment | What the approver wrote |
| Decided By | Who decided |
| Decided At | When |
Branch on Outcome when "nobody answered" needs a different follow-up from "someone said no". Both arrive with Approved set to no.
Link a financial exception
For a client financial policy, first use Request Client Financial Exception. When it returns an exception, map exception.id into Financial Exception ID on Request Approval in Assignar. Keep the request and approval steps in the same workspace, and choose people or roles with the current financial approval or override permission.
The reviewer opens the request in Approvals and decides it under Approvals and overrides. A general workflow approval without this link does not grant a financial exception. See Automate client financial reviews for the complete sequence.
For a linked request, Approved is no when the financial exception is pending, rejected, revoked, expired or already used. Outcome identifies the result, and Comment stays empty to keep the private financial review in Assignar Pay. Pay checks the current exception again when someone attempts the commercial action.
Patterns that work
- Only ask above a limit. Put a branch before the approval step: under the limit carries on, over the limit goes to the approval.
- Two approvers in turn. Add a second approval step after the first with different approvers. The second person is asked only once the first approves.
- Chase an unanswered request. Set Expires In (Hours) and, on the expired path, remind someone, notify a manager, or raise a new request with a wider group.
When the step fails
A role or person you named cannot be used, for example someone who has left, or a request names nobody at all. The step fails with the reason instead of pausing the workflow for ever. Fix the approvers and retry the step.
A workflow waits until someone decides, the request expires, or 30 days pass, whichever comes first. If the run ends before a decision, for example because it was cancelled in the builder, the request is marked Cancelled and there is nothing left to decide.