The Approval Workflow That Replaced Our Spreadsheet

The spreadsheet that depended on memory

At a research center, approvals lived in a shared spreadsheet. Someone added a row when a request came in, someone else was supposed to mark it approved, and a third person was supposed to check that the paperwork matched. It worked as long as everyone remembered their chore. Busy people do not remember chores, so the sheet drifted out of date, and the real status of any request lived in whoever had last emailed about it.

I replaced it with an approval-workflow application. The technology was the smaller part of the project. The useful part was deciding what a routed approval needs, and that applies whether you build in code, Power Automate, Make, or the forms tool you already pay for. Here is the order I would do it in.

Write down the path before you touch a tool

Start with one request type, not all of them. Walk a single real request from the moment someone asks to the moment it is closed, and write every hand-off on a page. For each step, note who acts, what they need to see, and what they can say. Most spreadsheets hide three or four steps that nobody wrote down, usually a check that one particular person does out of habit.

Then ask which steps are decisions and which are chores. A decision is a person looking at a request and choosing yes or no. A chore is everything around it: finding the right approver, copying details into an email, reminding someone, filing the result. Automate the chores. Leave the decision with a human. I made the case for that at more length in When to Automate, and When to Leave It Alone, and an approval chain is the clearest example of it.

What to automate

Four things earn automation in almost every approval chain.

Routing. The request goes to the correct approver based on a field, such as amount, department, or request type, instead of whoever the submitter thinks of first.
Prefilled context. The approver sees the amount, the budget line, the requester, and any prior related requests on one screen, so the yes or no takes seconds.
Reminders and escalation. A request that sits for two days nudges the approver, and one that sits for five goes to a named backup.
Filing the outcome. The decision is written to the record automatically, with who decided and when.

What to keep manual

Keep the judgment calls manual, and keep the exceptions visible. If a request does not fit the routing rules, it should land in a short queue that a person owns, not fail quietly or get forced down the nearest path. The exception queue is also your best source of improvements. When the same odd case shows up three times, it deserves a rule. Until then, a human reading it is the cheaper control.

I would also keep the first version small enough to explain in a minute. Every extra branch is something you will need to test, monitor, and explain to a new hire. A workflow with three approval paths that everyone understands beats one with twelve that only its builder trusts.

Make the audit trail a byproduct

The spreadsheet had no real history. You could see the current value of a cell, but not who changed it or when, and a changed cell erased what it used to say. A routed workflow fixes this almost for free if you design for it up front.

Record these at each step: the request as submitted, who acted, what they decided, the timestamp, and any comment. Never overwrite a record, only append to it. If a request is edited after approval, treat the approval as stale and send it back through, so the person who said yes is always agreeing to what will happen. This is also what makes year-end questions easy. When an auditor or a board member asks who approved a purchase and on what basis, the answer is one lookup instead of an email archaeology project.

Tie each record to a plain identifier that appears in every notification, such as REQ-0042. People will refer to requests by that number within a week, and it keeps conversations anchored to one record instead of three forwarded threads.

Why it survived

The application outlived the spreadsheet for a human reason. The spreadsheet needed people to update it. The workflow updated itself as a side effect of people doing their actual jobs: approving, declining, or asking a question. Nobody had to remember a chore, because the chore had been absorbed into the step.

It also stayed alive because it had an owner. When a policy changed, the workflow changed that week. An approval process is never finished, because the rules around it keep moving, and an unowned workflow turns back into a spreadsheet within a year as people route around it.

Start this week

Pick the one request type that causes the most chasing. Map its path on a single page, mark the chores, and build only the routing and the record. Skip dashboards and fancy rules for the first version. Run it beside the old sheet for a couple of cycles, then retire the sheet.

This is general educational information, not formal accounting, tax, or legal advice. I work non-attest, alongside your CPA, not in place of them.

If you are not sure which of your approval chains is worth building first, sorting that out is a core part of the Financial Operations Assessment. It is a flat-fee look at where your team's time goes and which fixes pay back soonest.