The problem: approvals happen in email, the rule is folklore
The version we hear on discovery calls — a composite, not a customer quote — goes like this. Approvals happen in email. Someone forwards a request, someone replies “fine”, someone else never sees it. Anything over a threshold is supposed to get a second signature. When finance asks who approved the laptop in March, somebody searches inboxes.
The process is not complicated. It is a form, a rule about who signs, a notification at each step, and a record at the end. What makes it painful is that none of those live in one place — so the rule is folklore and the record is a search.
What gets built: a request, a policy, a record of who said yes
Workflow automation has run on this platform for years: email notifications, multi-step approvals, conditional routing, and HTTP calls out to other systems. Your agent wires yours together through named operations.
- Objects:
apr_request,apr_step,apr_policy— real tables. A step points at its request; a policy says who signs for which type and amount. - Forms: the request form makes justification required over the threshold with a rule, not a reminder. The decision form is approve, reject or return, with a comment.
- Workflows: on submit, the steps are created from the matching policy and the first approver is emailed. Each decision emails the requester. The final approval posts the record to your finance endpoint through an ExternalService activity.
- Record: the change log is on for request and step, so “who approved this, and when” is a row, not an inbox search.
- Grids and groups: my pending approvals, all requests by status; only approvers can approve, enforced on the action itself.
Workflows run as asynchronous activity chains, and every run leaves an activity log you can read. We do not claim exactly-once delivery or automatic retries — so the record of who approved what lives in the app, in the change log, not in an email that may or may not land. If your chain needs a guarantee, raise it on a demo call and we will tell you what the platform does and does not do today.
Starter prompt
Build a solution called Spend Approvals for a team that approves purchase requests over email.
Objects: Request (requester, type as multiple choice: software / travel / equipment / other, amount, justification, attachment, status as multiple choice: submitted / in review / approved / rejected / returned); Step (request, approver, order, decision as approve / reject / return, comment, decided at); Policy (type, threshold amount, first approver, second approver).
Make justification required when the amount is over 5000.
Create Requesters, Approvers and Finance groups. Requesters see their own requests; approvers see steps assigned to them; finance sees everything.
Add a workflow that, on submit, creates the approval steps from the matching policy — one step under the threshold, two over it — and emails the first approver. Email the requester on every decision.
When the last step is approved, post the request as JSON to an HTTP endpoint I will give you.
Turn on the change log for Request and Step, add a grid of my pending approvals, and preview the diff before you commit.
Ship it: publish once, change the policy later
Requesters submit from a laptop or a phone; approvers get an email with a link and decide from the same app. Finance sees the whole queue and the log.
One operation ships it — publish-solution copies Current to Testing and Production — and the policy records stay editable without a republish. When the threshold changes next quarter, edit the policy. When the routing itself changes, your agent stages the edit, previews the diff and commits it as one save.
Integrations used
Each decision email is a workflow activity. The final approval posts JSON to any HTTP endpoint — Zapier, Make, n8n, or the finance system directly. A PDF of the approved request can be generated by the same workflow when a paper trail wants a file.
Related
- Blueprint: Approval workflow — the copyable primitives map and prompt.
- Closed in 24 Hours: A public intake portal live in 16 hours — an illustrative build where the intake becomes the request.
- Previous use case: Inspections and checklists.
- Next use case: Intake forms and surveys — when the request comes from outside.
Your IT lead will ask who can publish this, who can see the data, and what the agent is allowed to touch. The answers are written for them: the IT brief · security and governance.