Use cases
Build approval workflows with AI-assisted engineering
Turn email-thread approvals into a system: typed requests, threshold routing, delegation, escalation — and a record that stands up when audit asks.
Ciao is an enterprise AI-assisted engineering platform for building approval workflows — applications that take typed requests, route them by rules like amount thresholds and department, collect decisions and record everything in an append-only log. Unlike approvals run over email, every decision has an approver, a timestamp and the exact version reviewed. Workflow changes themselves go through Guardrails review, automated QA and security testing before merge.
Published 2026-07-03 · Last updated 2026-07-03
Approvals are a system, not a reply
An approval workflow does four things: takes a request, routes it to the right people, collects a decision, and records everything. Most companies run this over email — where a "looks fine" reply is the control. Nobody can say later what version was approved, whether the threshold policy was applied, or why a request sat for nine days in someone's inbox while they were on leave.
The gap becomes expensive at audit time. Auditors ask three questions: who approved this, what exactly did they see, and was the stated policy applied? Email answers none of them reliably. Neither do chat threads, and neither does a spreadsheet with an "approved?" column.
Ciao builds approval workflows as real applications: typed request forms, routing rules written down in code, delegation and escalation that handle real calendars, and an append-only record of every decision. The same discipline applies to the workflow itself — changing a routing rule or threshold is a governed code change with recorded review, not a quiet edit.
What an approval workflow actually requires
- Typed request forms — Spend, access, contract and exception requests each capture the fields the decision actually needs — validated at entry.
- Routing rules — By amount threshold, department, cost center, region or role — deterministic, versioned and readable when disputed.
- Multi-step chains — Sequential approvers, parallel approvers, and quorum rules for the decisions that need more than one signature.
- Delegation and out-of-office — Approvals reroute when someone is away — with the delegation itself on the record.
- SLA timers and escalation — Requests that sit too long escalate automatically; cycle-time reporting shows where things stall.
- Context on the request — Comments, attachments and linked records live on the request, so the approver decides from evidence, not memory.
- An append-only decision log — Who approved what, when, and the exact version they saw — immutable, exportable, auditable.
- Actions on approval — Integrations that create the PO, provision the access or update the ERP once the decision lands — closing the loop.
How an approval workflow build runs on Ciao
1. Write the policy down
"Spend under 1,000 needs a manager; above 10,000 adds finance; new vendors always add procurement." The rules, stated plainly, become the spec.
2. Generate forms and routing
Request types, fields, roles and routing land as a Supabase schema and readable routing code.
3. Handle the human calendar
Delegation, out-of-office rules, escalation timers and reminder cadence — the parts email never handled.
4. Wire the consequences
Approved requests act: a PO in the ERP, access provisioned in IT systems, a contract moved to signature — through controlled integrations.
5. Test decisions and boundaries
QA replays approval chains, threshold edges and permission boundaries — including the paths where someone tries to approve their own request.
6. Govern the rules themselves
Routing and threshold code is a Guardrails protected area: plain-English policies, risk detection, recorded human review on every change.
7. Deploy and report
Ship to your cloud, private VPC or on-prem. Cycle-time and bottleneck reporting comes from the same data.
Security and governance checklist
- ✓ Requesters cannot approve their own requests — enforced and tested
- ✓ Segregation of duties mapped into role tiers in the backend
- ✓ Append-only decision log with approver, timestamp and reviewed version
- ✓ Changes to routing rules and thresholds require recorded Guardrails review
- ✓ SSO via SAML or OIDC; approval links authenticate, never bypass
- ✓ Access-control probes run against the live app before flagging is trusted
- ✓ Delegations and escalations recorded alongside decisions
- ✓ Deployment to private VPC or on-prem where policy requires it
Approval workflow variations
Spend approvals
Requisitions routed by amount and cost center, with budget context on the request and a PO created on approval.
Contract approvals
Legal, finance and business sign-off in sequence, with the exact document version locked to each decision.
IT access requests
Role-based access requests with owner approval, time-boxed grants and a review trail for recertification.
Brand and campaign approvals
Creative review with versioned assets, markup comments and a record of who cleared what for launch.
Hiring requisitions
Headcount requests routed through manager, finance and HR, tied to budget and grade rules.
Policy exception register
Exceptions requested, justified, time-limited and approved — with expiry reminders instead of permanent quiet exceptions.
Approval requirements, covered
| Requirement | How Ciao covers it |
|---|---|
| Right approver every time | Deterministic routing rules versioned in readable code |
| Absences don't stall requests | Delegation, out-of-office rerouting and SLA escalation |
| Audit evidence | Append-only log: approver, timestamp, exact version reviewed |
| No self-approval | Role separation enforced in the backend and tested in QA replays |
| Decisions cause actions | Integrations create POs, provision access, update systems of record |
| Rule changes are controlled | Guardrails review recorded before routing or threshold changes merge |
| Restricted environments | Own cloud, private VPC or on-prem deployment options |
Frequently asked questions
How do we prevent someone approving their own request?
Role separation is enforced in the backend — the routing engine excludes the requester from their own chain — and QA replays include the self-approval attempt as a tested failure case. Access-control probes confirm the boundary on the live app.
What do auditors actually get?
An append-only log per request: requester, approvers, timestamps, the exact version each approver saw, comments and attachments. On the engineering side, the audit trail also covers who changed the workflow rules themselves and who reviewed that change.
Can business users change routing rules safely?
Rule changes are described in plain language but ship as governed code changes: Guardrails detects that a threshold or routing rule moved, applies your plain-English policies and records human review before merge. The change is fast — and on the record.
Can approvals trigger actions in our ERP or IT systems?
Yes. Approved requests can create purchase orders, provision access or update records through controlled integrations, and custom sandboxes let that integration work happen against Rails, Java, Go, Python and Node backends.
Can this run inside our network boundary?
Yes — your own AWS, Azure or GCP account, private VPC, or on-prem under separate terms, with SSO via SAML or OIDC and optional MFA.
What does it cost?
Approval workflows are usually part of a broader governance program rather than a single app. Serious development programs start at USD 10,000 per year; sales can scope your approval landscape — spend, access, contracts — in one conversation.
Related pages
Serious development starts with serious responsibility.
Build Approval Workflows with AI-Assisted Engineering | Ciao