On this page
Short answer: an approval workflow app is a shared list of requests where every request has an owner, a status and a next approver, and the app moves it along for you. Someone submits a request through a form, rules decide who approves it, the approver sees it in their own queue and presses Approve or Reject, and the requester is told the result. Every decision is recorded with who made it and when. Expense reports, purchase requests, time off, contract reviews and discounts all follow that shape. This guide covers the parts every approval app needs, the point where email and a spreadsheet stop being enough, the tables and workflows behind one, and how to build your own on Tadabase AI.
Describe the workflow app you need — we’ll build it now.
We started the prompt for you. Edit it, or describe your own app.
What an approval workflow app has to do #
Whatever is being approved, the app needs the same seven parts. If one is missing, the approval moves back into someone's inbox.
| Part | What it looks like in practice | What to check before you commit |
|---|---|---|
| Request form | A form with the fields the approver needs: amount, reason, dates, attachments | Can the form require the fields and files the approver will ask for anyway? |
| Routing rules | Under $1,000 goes to the manager; over it also goes to finance | Can the rules use the request's own values, such as amount, department or type? |
| Approver queue | Each approver sees the requests waiting for them, oldest first | Does an approver see only their own queue, or every request in the company? |
| Decision | Approve, Reject or Send back, with a comment | Does pressing the button record who decided and when, without anyone typing it? |
| Notifications | The approver hears about a new request; the requester hears the result | Can you change the wording and the timing yourself? |
| Reminders | Requests waiting more than two days get a nudge | Can a schedule find stuck requests on its own? |
| Audit trail | Every request shows its history: submitted, routed, approved, by whom | Can you show an auditor who approved a given request a year from now? |
Approvals that fit this shape #
Most teams have more of these than they think. Each one is the same app with different fields and rules.
- Expense reports: receipts attached, manager approves, finance approves anything over a limit, then pays.
- Purchase requests: a request becomes a purchase order once approved, with the order created from the request's own fields.
- Time off: the manager approves, and the team calendar and balance update when they do.
- Contract and document review: legal, then the budget owner, then a signature, each with comments kept on the request.
- Discounts and pricing exceptions: a sales rep asks, a sales lead approves above a set percentage.
- Vendor and customer onboarding: documents collected, checks completed, an account created only after sign-off.
- Content and publishing: a draft goes to an editor and then to the person who owns the page.
When email and a spreadsheet stop working #
Most approvals start as an email to the boss and a row in a shared spreadsheet. That works while the volume is small and everyone sits in the same room. It breaks at four predictable moments.
- Nobody knows where a request is. The requester asks, the manager searches their inbox, and finance has a different status in the spreadsheet.
- A second approver joins. Finance now signs off on anything over a limit, and the email gets forwarded with half the context missing.
- Someone needs part of the data, not all of it. You cannot share one row of a spreadsheet with the person who submitted it without sharing the rest.
- Someone asks who approved it. An auditor, a customer or a new manager wants proof, and the answer is somewhere in an email thread.
If none of those has happened yet, keep the email. When the first one does, write down the steps your approvals already follow; that list is the design of the app.
The tables behind an approval app #
These are the tables the AI proposes when you describe an approval process. Each is a typed table with fields, linked to the others.
- Requests: type, amount, reason, dates, attachments, the requester, the current approver and a status such as Draft, Submitted, Approved, Rejected or Sent back.
- Decisions: one row per approval step, linked to the request, with the approver, the decision, the comment and the date. This table is the audit trail.
- People: each person's role, department and manager, so the rules can route a request to the right approver.
- Approval rules (optional): limits per department or request type, kept in a table so finance can change a limit without editing a workflow.
The links do the work. A request knows its requester and its current approver; a decision knows its request. "A requester sees requests they submitted" and "an approver sees requests where they are the current approver" are the whole access model, and the platform enforces them per row on the server.
The workflows that move a request #
Each moment in the life of a request is one workflow: a trigger and a short list of steps. These five cover most approval apps.
| Moment | Trigger | Steps |
|---|---|---|
| A request is submitted | Record Created on Requests | A condition checks the amount and type, an Update Record step sets the current approver, and Send Email tells them |
| The approver decides | Manual, from an Approve or Reject button on the request | Update Record sets the status, Create Connected Record writes the decision with the logged-in user and the date, and Send Email tells the requester |
| A second approval is needed | Record Update on Requests | Branches send a request approved by the manager and over the finance limit on to finance; smaller ones are done |
| A request is stuck | Schedule, every morning | Record Selection finds Submitted requests older than two days, and a loop emails each approver a reminder |
| An approved request needs a document | Record Update, when the status becomes Approved | Create PDF Form produces the purchase order or approval letter, and Send Email delivers it |
Conditions match on values such as is, is not, contains, higher than and lower than, and branches send each request down the first path whose rules it matches, so a three-level chain is three branches, not three apps. Integration steps can post the result to Slack or create the bill in QuickBooks or Xero, and a Run Custom Code step (JavaScript or Python) covers the calculation no other step does.
Build it on Tadabase AI in an afternoon #
Describe the approval process in a paragraph and the AI builds the first version with the database, logins, roles, workflows and hosting behind it. A description that works well:
A purchase request app: employees submit a request with an amount, a vendor, a reason and a quote attached. Requests go to the employee's manager; anything over $5,000 then goes to finance. Approvers see only the requests waiting for them and can approve, reject or send back with a comment. Employees see only their own requests and their status. Record every decision with who made it and when, email the approver when a request arrives and the employee when it is decided, remind approvers about requests waiting more than two days, and create a PDF purchase order when a request is approved.
Then make it yours, in this order:
- Check the roles. Employee, approver and finance are roles with row-level rules: requests connected to the logged-in user for employees, requests where they are the current approver for approvers. If a field such as the budget code should be hidden from employees, a field-level rule hides it for that role.
- Keep the decision fields off the requester's form. The status and the approver are set by workflows, not typed by the person asking.
- Read the workflows and edit the words. Each workflow is a list of steps you can open. Change the limits, the routing and the email wording; the workflows page in the docs lists every trigger and step.
- Bring your people. Import the people table from a CSV with each person's manager and department, so routing works on day one.
- Run a dry run, then one real request. Submit a small request and a large one, and watch each take its own path in the History.
The AI follows the same rule #
Approval is also how Tadabase AI treats its own changes. An AI agent in your app takes an action only after a person approves it in the chat, and a change to the structure of a live app shows a plan and an impact summary and waits for your approval before anything moves. The app you build for your team's approvals runs on a platform that asks before it acts.
Common questions #
Can I try an approval workflow app for free? Tadabase AI has a 14-day free trial with no card, so you can describe your approval process, build the app and try it with real requests before paying anything.
Can requesters see only their own requests? Yes. A row-level rule shows each requester the requests connected to them and nothing else, and the server decides, per row, not the screen.
Can it handle multi-level approvals? Yes. Conditions and branches route a request by its own values, such as amount, department or type, so a request can go to a manager, then finance, then a director.
Can I see who approved what, and when? Yes. Each decision is a record with the approver, the decision, the comment and the date, and every workflow run is kept in its History with each step it took.
Does it connect to Slack or our accounting tool? Workflow steps include Slack, QuickBooks, Xero and many other tools, plus a Custom API step for anything else.
Do I need to know how to code? No. Describe the process, then change the fields, roles and workflow steps in settings. A custom code step is there if you want it, not because you need it.
What if our process changes next quarter? Change the limit, add an approver or add a step to the workflow. The requests already in the app keep their history.
Where to start #
Pick the approval that causes the most chasing today and write down three things: who asks, who approves at which amount or type, and who needs to know the result. That is the paragraph to give the AI. Build that one app, run it for a month, and the next approval is a copy with different fields. The guide to roles and permissions on the blog covers the access side in more depth, and every account starts with a 14-day free trial.