Every request that needs a signature, from leave and travel to expenses, purchases, company stamps and finance sign-offs, runs through one engine. Approvers are resolved from a live org chart, every decision is logged, and the signed document files itself into SharePoint. Five months from first commit to live, and still growing.
What they had
A group of energy companies: several legal entities, one set of people running operations across all of them. The rules for who approves what lived in two policy documents and an org chart in Excel. The approvals themselves lived on paper: printed forms, wet signatures, company stamps, walked from desk to desk and filed somewhere. Nobody could say where a request was, who was sitting on it, or how long approvals took. Not because nobody asked. Because nothing was recording it.
What we built, in the order we built it
We didn't digitize forms. We built the system the forms run on.
1. An org model that's the source of truth
Companies, units as a tree, positions, and who held which position when, with dates. The Excel org chart became a database, the database became a live org chart, and the org chart became the routing table. A new request goes to whoever holds the position today, not whoever held it when the form was designed.
2. A workflow engine, not a pile of forms
A workflow is data. It has:
- ordered steps
- an approver rule per step: the unit head (climbing the tree when needed), a fixed role like finance, or the requester
- conditions that decide whether a step exists at all
- separate approval and completion phases
- revision cycles that keep every round on record
One engine runs 70+ approval steps across every flow: leave, overtime, travel, expenses, advances, purchase comparisons, company-stamp requests, finance and accounting sign-offs, onboarding and offboarding.
3. Documents are the output, not the input
Every flow ends in a PDF the system generates itself: the right template, the full approval history, signatures where the policy wants signatures and the company stamp where it wants a stamp. Attachments travel with it. Nobody retypes anything into Word.
4. Wrap Microsoft 365, don't replace it
The company already lived in Microsoft 365, so the platform lives there too. Sign-in is company SSO through Entra ID. Notifications go out as Outlook email through Microsoft Graph. The home screen shows your calendar and your To-Dos. The finished PDF files itself into SharePoint through a queue with retries and a kill switch, so a SharePoint hiccup delays a document instead of losing it.
5. A lifecycle people can trust
Withdraw, revise, cancel, resubmit, with rights that depend on how far the request has gone. Before the signatures, the requester is in control. After them, only an admin. Every revision round stays in the audit trail.
Guardrails
Row-level security in Postgres, around 160 policies: you see a request if it's yours, if it's yours to approve, or if you're an admin. Sign-in only through the company's own SSO. A privacy consent screen before anyone gets in. Server-side keys never leave the server. Every approval step records who acted, when, and in which revision.
Where the AI is
Not in the approval path, on purpose. A signature is a legal act, and nobody wants a model guessing who should sign a finance document. The AI is in how the system is built, run and handed off.
- AI-native delivery. Claude Code worked as our third engineer throughout. It works from a project playbook that encodes the system's rules: time zones, revision cycles, which database client goes where.
- Read-only by default, for agents too. Our agents can query development and production but can't write to either; writes are blocked at the database level. The agent drafts the SQL, and a human reviews it and runs it. It's the rule we put on every agent we ship: reads are the default, writes are earned.
- Onboarding for humans and their agents. The handoff doc is written for a new developer and the AI assistant they bring. The client's own developer onboarded with it.
- Next up: an on-prem assistant. On the roadmap: a language model running inside the company's own infrastructure that answers questions from the platform's data. It's planned to read through the same access rules as everyone else, and nothing leaves the building.
What broke
Three things, all in production, all fixed.
- Approvals nobody gave. Steps whose condition didn't apply were being recorded as approved, so some documents looked like the requester had approved their own request. Now a step that doesn't apply doesn't exist.
- A cancel that didn't stick. An approver rejected a request its owner had already cancelled, and the rejection won. Now every decision checks the request's status first, and who can cancel depends on the phase.
- A page that only broke in production. Request details wouldn't open on in-app navigation. The session cookie was carrying tokens it didn't need and had grown past what the HTTP/2 connection would carry. We slimmed the cookie, and the pages opened.
What changed
Monthly volume grew fourfold in the first four months live. The median time from submission to fully approved is under 17 hours, and two out of three requests are fully approved within a day. More than 8,000 signed documents have filed themselves into SharePoint without anyone dragging a file into a folder.
The policy documents finally have a counterpart that enforces them. When a rule changes, it's usually a configuration change, not a release. Adding an optional document to a leave step and handing the final step of a flow to a different person both shipped without a deploy.
Timeline
- January 2026: we landed. We read the policies, mapped the org chart, and watched how a request actually moves.
- June 2026: live, with the org model, the engine and the full set of flows.
- Since then: new flows and steps as the business asks for them, plus a twelve-month roadmap going deeper into leave balances, asset tracking, performance reviews, a mobile app and the on-prem assistant.
Still embedded. Not a hostage situation.