Getting a Business Process Off Email and Spreadsheets

Capital expenditure requests are a good example of the genre. They are important enough that people take them seriously, infrequent enough that nobody automates them, and just structured enough that a spreadsheet feels adequate for the first two years.

How these processes usually look

Someone downloads a request template. They fill it in, attach quotes, and email it to their manager. The manager forwards it to finance. Finance checks it against a threshold table that lives in a different workbook, and either approves it or sends it up. At some point a version of the file lands in a folder, and that folder becomes the record.

It works. That is the part people underestimate when they propose replacing it. The process has absorbed a decade of exceptions, and most of them are undocumented because they live in the head of whoever has been doing the finance check.

Why it eventually stops working

Usually one of three things: an auditor asks a question nobody can answer from a mail thread, the volume grows past what one person can track, or the person who understood the exceptions leaves. In practice it is often the third.

Where Power Platform fits

This is squarely the shape of problem Power Platform was built for — structured data, an approval chain, users who already have Microsoft 365. The tooling is not the hard part. Deciding what the process actually is, so it can be encoded, generally is.

The process has no single source of truth, no reliable audit trail, and no way to answer basic questions without asking a person.

What that looks like day to day

• Requesters do not know where their request is. They ask, which generates more email.
• Approvers get a forwarded attachment with no context about what has already been checked.
• Finance maintains the real register by hand, reconciling it against email when something looks wrong.
• Audit asks who approved a spend and on what basis. The answer is assembled retrospectively from mailboxes, which is slow and never entirely convincing.

The technical problems underneath

• The workbook is the record and the working copy at the same time, so every edit is a potential corruption of history.
• Threshold rules exist in two places — the policy document and the workbook — and they have quietly diverged.
• Attachments live in mailboxes, so the evidence supporting a decision is not stored with the decision.
• There is no concept of a request state. Something is approved when the last person in the chain says so in a reply.

What it costs

Mostly it costs finance time and organisational patience. It also carries a real control weakness: an approval that exists only as an email is hard to evidence and easy to dispute. That is the argument that usually unlocks funding, and it is a legitimate one.

Written so someone can later say whether they were met.

Before designing anything, it is worth mapping what the process actually does rather than what the policy says it does. Those are usually different documents.

The thing you only find by sitting with people

There is nearly always an informal pre-approval step. Someone checks with finance before submitting, so the formal request is a formality by the time it arrives. If you encode the formal process and ignore the informal one, adoption suffers and nobody can explain why. It is worth designing for.

This gets asked now on every project, so it is worth answering directly rather than leaving it implied.

For this process, AI is not the right tool. The work is deterministic: a value goes over a threshold, a specific role approves it. That is a rule, and rules should be written as rules — they can be tested, explained to an auditor, and changed by someone who is not an engineer. Wrapping a probabilistic model around it makes it harder to defend and no faster.

There is a narrow, genuinely useful case around extracting figures from supplier quotes, but it sits outside the approval path and belongs in a later iteration once the process itself is stable. Bolting it on at the start would mean debugging two new things at once.

Four options were worth taking seriously. The first two get dismissed too quickly on projects like this, so they are argued properly here.

Dataverse underneath, two front ends on top, and the approval logic in the platform rather than in the app.

The split, and why

• Model-driven app for finance and admins. They live in this thing daily, need views, filtering and bulk actions, and benefit from a UI that is generated rather than hand-built. Nobody has to maintain a screen layout for them.
• Canvas app for requesters. Occasional users on phones. They need a short, guided form, not a CRM. Roughly six fields and an attachment.
• Power Automate for approvals and notifications, triggered by state changes rather than by a button. If a request reaches "awaiting finance", the flow does not care how it got there.
• Business rules and column security in Dataverse, so validation holds even when a record is touched by an integration or an admin rather than through the app.

The decision that matters most

Thresholds live in a configuration table that finance maintains, not in flow conditions. When the policy changes — and it does, usually at year end — nobody needs a developer, and there is a dated record of what the threshold was when a given request was approved. That last part is what audit actually asks for.

Where humans stay

Every approval is a person. There is no auto-approve below a threshold, because "small" purchases are exactly where duplicate and split spending hides. The system routes and records; it does not decide.

Deliberately small. The interesting parts are the data model and where validation lives, not the topology.

Nothing exotic. The judgement is in which pieces are used for what, not in the list.

Four decisions that shaped the build. Two of them are the ones I would defend hardest a year later.

Short phases with something usable at the end of each. The pilot deliberately runs against the real process rather than a rehearsal.

These are the numbers this design is meant to move, with the reasoning behind each so you can argue with the logic rather than the digit.

Including the two that most often kill this kind of project, neither of which is technical.

Who can see what

Dataverse security roles do the work here. Requesters see their own requests and, depending on the department, their team's. Finance sees everything. Column-level security hides commercially sensitive fields — supplier pricing, mainly — from roles that have no reason to see them. This is one of the concrete advantages over a list-based build, where field-level control is limited.

Evidence and audit

Dataverse auditing is the decision history. Building a custom log table is a common instinct and usually a mistake: it captures what the developer thought to capture, and it does not capture changes made outside the app. Platform auditing catches both.

Attachments inherit the record's security. Keeping evidence with the decision rather than in a separately-permissioned library is what makes the audit story hold together.

Change control

The solution moves between environments as a managed solution. Finance can change thresholds in production because that is configuration data with its own history — but they cannot change the app, and the distinction is enforced by security roles rather than convention.

Data retention

Capex records usually carry a statutory retention period, and it is normally longer than anyone's instinct. Worth confirming with finance during discovery rather than assuming a default, because retroactively extending retention on data you have already deleted is not a solvable problem.

What this design gives up. The first one is the significant one.

The recommendation, and the condition that would change it.

Public product documentation used to check platform behaviour and limits.