Internal approval routing
A request enters once, follows the right decision path and returns with a visible owner, deadline, rationale and next step.
Case note
The implementation was treated as a small operating system: visibility first, ownership next, automation only after the workflow was clear.
Use case
Internal approval routing
A request enters once, follows the right decision path and returns with a visible owner, deadline, rationale and next step. A growing operations team handled vendor, purchase, content and access decisions through inbox and chat. Requesters could not see ownership, approvers received incomplete context and managers discovered blocked work only after deadlines moved.
Result: The company gains a lightweight decision system without the weight of a procurement suite. Requests follow policy, approvers see a decision-ready brief and every outcome returns to the requester with a traceable reason.
Workflow map
Approval workflow from request to decision log
Every request gets an owner, a visible status and a final decision record.
Main database: Supabase
The workflow uses Supabase as the source of truth: it stores each record, status, and key event so the team can see what happened, retry failures, and debug without searching every tool.
Tool icons
System rationale
A lightweight approval system beats invisible chat approvals
This workflow keeps approvals simple but inspectable: every request has a rule, owner, due date, reminder path and final decision record.
Routing rules reduce ambiguity
The requester does not need to know the org chart; the workflow assigns the correct approver from category and policy.
Reminders protect momentum
Overdue work is visible before a blocked request becomes an operational surprise.
Decisions become reusable history
Approve, reject and revise decisions stay attached to the original request with reason and timestamp.
Add-ons that fit on top
The starting point
A growing operations team handled vendor, purchase, content and access decisions through inbox and chat. Requesters could not see ownership, approvers received incomplete context and managers discovered blocked work only after deadlines moved.
The diagnosis used real volume, connected tools, decision points and exceptions. The question was not only what to automate, but what proof would show that the workflow had completed correctly. The operating proof mattered as much as the automation.
The implementation
Ductio created a lightweight approval operating layer: one intake, routing rules by category/amount/team, owner assignment, due dates, reminders, requester updates and a decision log.
The implementation separated rules, free-text context, human decisions and external effects. That let the system improve daily work without turning every exception into a black box. AI as support inside the process, not as autopilot.
What was used
Tooling was chosen from the process outward, not from a pre-decided technical preference. Each piece needed a clear owner, a stable integration path and a simple way to inspect errors.
In practice, the build combined Form intake, Supabase, Python/FastAPI, Resend, Approval log. The tools visible to the team stayed close to their daily work, while integration logic was documented and kept separate from sensitive commercial decisions.
The improvement showed up in daily work.
Rather than treating the result as a dashboard, the team felt it in three specific moments: less manual preparation, less context hunting, and fewer doubts about who needed to act.
Status checks: Requester follow-up messages moved from Frequent to Half.
Owner clarity: Requests with assigned approver moved from Low to High.
Overdue visibility: Aging requests tracked moved from Hidden to Visible.
Before/after proof
What changed in the operation
Before
After
Visible artifacts
- Approval matrix
- Request log
- Reminder schedule
- Decision record
- Overdue queue
- Requester notification examples
Controls
- Approver rules visible
- Overdue escalation
- Decision audit log
- Requester update after decision
- Rejected/revise path records reason
What changed after launch
The company gains a lightweight decision system without the weight of a procurement suite. Requests follow policy, approvers see a decision-ready brief and every outcome returns to the requester with a traceable reason.
The result was not only saved minutes. The team gained a shared sequence for reviewing inputs, understanding context, deciding, acting and checking that the workflow had been recorded. 50% fewer status checks
The workflow in one line
How it was built
A form submission writes a Supabase request row, Python/FastAPI applies routing rules, Resend notifies approvers/requesters, overdue reminders are scheduled, and final decisions are written back to the approval log.
The stack was pragmatic: Form intake, Supabase, Python/FastAPI, Resend, Approval log. Tools were chosen for ownership, integration and maintainability, not for theater. The result is a system the team can understand and operate.
What was delivered
- Request form
- Approval matrix
- Owner assignment
- Due-date reminders
- Requester updates
- Overdue escalation
- Decision log
- Request ownership became visible to approvers and requesters.
- Repeated status-check messages dropped by about half.
- Overdue requests were visible before they became blockers.
- Approvers received the context they needed in one message.
- Every approve/reject/revise decision was logged with reason and timestamp.
- The same pattern could support purchase, vendor, content and access approvals.
- Managers can distinguish policy bottlenecks from individual delays and improve the routing model over time.
