Build an approval workflow app
How to build an approval workflow app with AI
To build an approval workflow app, describe who it is for and what they do in it, and let Forge64 plan and generate the app. Customer organisations raise requests (purchases, expenses, access) that route through tenant-configured approval chains by amount; nobody approves their own request; overdue requests escalate; decisions are recorded with who, when and why; seats and subscriptions are billed per tenant; API keys, notifications, exports and an append-only audit trail. The core parts of a first version are tenants, members and invitations, role matrix, policy-driven approval chain, maker-checker separation and append-only audit trail.
Last checked
What the first version needs
These are the parts a approval workflow app needs before it is useful. Each one is something the plan covers.
- Tenants, members and invitations: Each customer organisation is a tenant whose data is invisible to every other tenant.
- Role matrix: Owner, admin, approver, member and viewer with distinct capabilities.
- Policy-driven approval chain: Choose the approvers from tenant-configurable policies by amount threshold, not hard-coded rules.
- Maker-checker separation: Nobody may approve a request they raised; decisions record who, when and why.
- Append-only audit trail: Everything that changes state is recorded and cannot be edited.
- In-app and email notifications: Tell approvers and requesters what needs attention.
- SLA escalation: Requests that sit past their SLA move to the next approver.
- API keys: Let tenants integrate with their own systems.
- Rate limits: Protect invites, API keys and public endpoints from abuse.
The data it stores
Each table below becomes part of the Postgres database that belongs to your app.
- tenants: seat_limit is written only by the billing webhook.
- memberships: role: owner|admin|approver|member|viewer.
- invitations: 32 random bytes stored only as a hash; single use; expires.
- requests: amount in integer minor units; status is a state machine with legal transitions only.
- approval_policies: bands must not overlap within a tenant, validated on write.
- approval_steps: status: pending|approved|rejected|escalated.
- approval_decisions: CHECK decided_by differs from the request's requester, enforced by trigger.
- audit_log: insert-only; UPDATE and DELETE are refused by trigger.
- api_keys: the full key is shown once and never stored.
Pages and endpoints
| Route | Who can use it | What it does |
|---|---|---|
| /requests | authed | my requests and the approvals waiting for me. |
| /api/requests | authed | create and list requests; validated input, tenant scoped. |
| /api/requests/[id]/decision | authed | approve or reject a step; refuses the requester. |
| /settings/policies | authed | approval policies by amount band. |
| /settings/members | authed | members, roles, invitations and seat usage. |
| /api/exports/requests | authed | CSV export of requests. |
| /api/health | public | health endpoint. |
What to leave out of version one
- No approval rules in code: policies are tenant data.
- No ERP connectors or chat bots in phase 1.
- No storing card data.
- ERP and chat integrations: plan for it, build it later.
How Forge64 builds it
Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.
This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.
FAQ
- What does an approval workflow app need first?
- Tenants, members and invitations, role matrix, policy-driven approval chain, maker-checker separation, append-only audit trail and in-app and email notifications. The plan for a approval workflow app covers all of these before it generates code.
- What should I leave out of the first version of an approval workflow app?
- No approval rules in code: policies are tenant data. No ERP connectors or chat bots in phase 1. No storing card data.
- Which products define the approval workflow app category?
- Well-known examples include Ramp, Spendesk, Coupa, Procurify and Airbase. Use them to decide which features your users expect, then describe your own version.
Build your app with Forge64
One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.
Start building for free