Work · Internal operations / Approval engine
RT Enerji
Every approval, one engine.
What it is
An approval engine for RT Enerji, a group of energy companies. Every request that needs a signature — leave, travel, expenses, purchases, company stamps, finance sign-offs — runs through one engine: approvers are resolved from a live org chart, every decision is logged, and the signed PDF files itself into SharePoint.
Why it needed to exist
Approvals lived on paper: printed forms, wet signatures and 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 — because nothing was recording it.
What Idealink did
A partnership project built by the 2bros1ai team, Affan and Furkan Dindar: the org model, the workflow engine, generated and signed documents, the Microsoft 365 integration and the request lifecycle. Five months from first commit to live in June 2026, and still embedded.
- Status
- Live
- Relationship
- Partnership
- Industry
- Energy
- Period
- 2026 — ongoing
- Platform
- Web · Microsoft 365
- Idealink role
- Partnership project built by 2bros1ai: discovery, org model, workflow engine, signed documents, Microsoft 365 integration
Thesis
The rules for who approves what lived in two policy documents and an Excel org chart; the approvals lived on paper. We didn't digitize forms. We built the system the forms run on.
The approval engine: requests move through workflow steps whose approvers come from the live org chart, end in a signed and stamped PDF and file themselves into SharePoint. Sign-in runs through Entra ID, notifications through Outlook.
02
Before and after
From the production database, late September 2026. No screenshots: the product carries the client's branding.
- How an approval moves
- Before: printed, signed, walked desk to desk. After: one engine, approvers resolved from the org chart.
- Time to fully approved
- Before: unknown — that was the problem. After: median under 17 hours, two-thirds within a day.
- Where the signed document ends up
- Before: a folder, a drawer, someone's inbox. After: 1,300+ filed in SharePoint, automatically.
- Approval steps on record
- Before: whatever the paper said. After: 5,000+, with who, when and which revision.
- People on the platform
- Before: 0. After: 70+.
- Changing a rule
- Before: reprint the form, tell everyone. After: usually a config change, not a release.
03
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.
04
What we built, in the order we built it
We didn't digitize forms. We built the system the forms run on.
An org model as the source of truth
Companies, units as a tree, positions, and who held which position when. The Excel org chart became a database, the database a live org chart, and the org chart the routing table: a request goes to whoever holds the position today.
A workflow engine, not a pile of forms
A workflow is data: 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; separate approval and completion phases; revision cycles that keep every round on record. One engine runs 70+ approval steps across leave, overtime, travel, expenses, advances, purchase comparisons, company-stamp requests, finance and accounting sign-offs, onboarding and offboarding.
Documents as the output
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.
Wrap Microsoft 365, don't replace it
Sign-in is company SSO through Entra ID. Notifications go out as Outlook email through Microsoft Graph, and 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.
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.
05
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, with 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.
06
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 the third engineer throughout, 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. 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 and runs it. Reads are the default, writes are earned.
The handoff doc is written for a new developer and the AI assistant they bring; the client's own developer onboarded with it. Next on the roadmap is an on-prem language model inside the company's infrastructure, planned to answer from the platform's data through the same access rules as everyone else, with nothing leaving the building.
07
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. The cookie was slimmed, and the pages opened.
08
Timeline
January 2026
Landed
Read the policies, mapped the org chart, and watched how a request actually moves.
June 2026
Live
Live with the org model, the engine and the full set of flows.
Since then
Growing
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.
The policy documents finally have a counterpart that enforces them.
Outcome
Where it stands
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 1,300 signed documents have filed themselves into SharePoint without anyone dragging a file into a folder.
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. Still embedded. Not a hostage situation.
Stack and capabilities
Only what mattered
- Next.js
- TypeScript
- Postgres · Supabase (RLS, Storage, Realtime)
- Microsoft Entra ID SSO
- Microsoft Graph (Outlook, Calendar, To-Do, SharePoint)
- Signed and stamped PDF generation
- pg_cron
- Vercel
- Claude Code