Write the process down before you automate it

To prepare a process for automation, write it on one page before anyone opens a designer: the trigger, the steps with the role that does each one, the decision points and their actual rules, the exceptions, and a single owner. Then have two people who run the process write it independently and compare. If their versions differ, you have found the real problem.

The most expensive automation projects are the ones where the process was discovered during the build. One page, written first, prevents most of it.

Why the page matters

When a process is discovered during the build, every unknown becomes a pause. The builder asks what happens when the approver is on leave; nobody knows; a meeting gets booked; the answer changes a week later. Each loop costs days and a rework of logic already built.

The page

There are five parts. None of them needs a template tool or a diagramming licence; a SharePoint page or a Word document is fine.

Trigger. What starts this? Be specific — "when a purchase request over $5,000 is submitted", not "when we need to buy something".

Steps. Numbered, in order, each with the role that performs it. Roles, not names, so the page survives staff changes.

Decision points. Every place where the path can branch, and the actual rule. "Manager approves" is not a rule. "Under $5,000 the manager approves; over that, the manager and the finance lead" is.

Exceptions. What happens when the approver is on leave? When the request is urgent? When it is rejected — does it die or come back amended?

Owner. One name. The person who decides how this process works.

A filled-in example

Here is what one page looks like for a purchase request. The values are illustrative; yours will differ.

Notice what is missing: no screens, no fields, no connectors. Those come later. The page describes the business process; the builder decides how to implement it.

The test

Have two people who run the process write it independently. Then compare.

If the two versions differ, you have not found a documentation problem — you have found the actual problem. The process is being run two different ways, and automating either version breaks it for half the business.

This half-hour exercise regularly saves five figures.

Typical differences are small on paper and large in practice: one site sends urgent requests to the operations manager, another to the director; one team attaches quotes, another sends them separately by email; one person treats GST-inclusive values as the threshold, another GST-exclusive. Any one of those, built into a flow, means half the requests get routed wrongly.

Resolve each difference with the owner, in writing, before scoping. Some will need a policy decision. That is fine — it was always going to need one, and it is far cheaper to make it now than after the flow is live.

Exceptions deserve most of your attention

Teams describe the happy path in five minutes, then spend an hour on exceptions. That ratio is inverted in reality: exceptions are where the time goes, and where automation either succeeds or generates a new class of problem.

If more than one in five cases is an exception, fix the process before automating it.

To check, go back to the last twenty or so real cases and mark each one as either a straight run or an exception. It does not need to be precise. If four or more out of twenty needed someone to step outside the written steps, the steps are wrong, not the people.

Not every one will apply. Asking each one takes a few minutes and surfaces most of the surprises that would otherwise appear in week three of the build.

Who should write it

Not the person commissioning the automation, and not the builder. The page should be written by the people who run the process every week: the site administrator who raises purchase requests, the accounts officer who turns them into purchase orders, the supervisor who approves timesheets on a Friday afternoon.

Managers tend to write the process as the policy describes it. The people doing the work write it as it happens. The gap between those two versions is useful information too, so if you have time, collect both.

The owner's job is different. They do not write the page; they settle every difference between the versions and sign off the final one. If nobody has the authority to do that, stop there — a process without an owner is not ready to automate, however well it is documented.

Common ways the page goes wrong

• It describes the system, not the process. "Click submit, then the status changes to Pending" is a user guide. Write what people do and decide, not which buttons they press.
• It uses names instead of roles. "Send it to Sarah" stops working the week Sarah takes leave.
• The rules are vague. "Large purchases need finance approval" invites argument. Write the number.
• It runs to four pages. If it does not fit on one, it is probably two processes. Split it and automate the simpler one first.

What the page does after the build

The page does not go in a drawer once the flow is live. It becomes three things:

• The test plan. Every step, rule and exception on the page is a test case. If the flow handles each one, it is ready.
• The handover document. Whoever maintains the flow next year reads the page first. Pair it with the technical notes in our handover documentation checklist.
• The change log. When the threshold changes or a step is removed, update the page first, then the flow.

If you are preparing an app rather than a flow, the same page is the first section of the scoping checklist for your first Power App. And if you suspect the process has approval steps that no longer earn their place, run a 20-minute audit of your approval process before writing the page, so you document the version worth keeping.

What to do next

Pick the process you most want automated. Ask two people who run it to write the one page separately, without conferring, and give them thirty minutes. Then sit down with the owner and compare. Resolve every difference, mark the exceptions, and only then decide whether — and what — to build.

If you would like help running that comparison across a few processes, it is part of the free diagnostic audit.

Automating a process you cannot describe on one page is how you get a flow nobody can maintain.