A workflow automation case study is only useful if it shows what changed in the working day. Not a diagram of an ideal process, but the emails that stopped arriving, the spreadsheets people no longer had to update, and the approvals that no longer sat unnoticed in someone’s inbox for a week.

This example is based on a common Microsoft 365 scenario seen in small and mid-sized organisations: a growing business with a capable team, an existing SharePoint environment, and a purchasing approval process that had become unnecessarily slow.

The organisation did not have a technology problem in the usual sense. It had Microsoft 365 licences, SharePoint document libraries and Teams already in use. Its problem was that the process lived across inboxes, attachments and a manually maintained tracker. Nobody could see the full position without asking around.

The starting point: a process held together by email

The process covered requests for non-routine purchases, from software subscriptions and equipment to external services. An employee completed a spreadsheet, attached it to an email and sent it to their line manager. If the request exceeded a spend threshold, it moved to finance and then to a director.

This worked when requests were occasional. It became a problem as volumes grew.

Employees did not know whether their request had been received, approved or held up. Managers received approval emails among routine correspondence and sometimes missed them. Finance spent time checking values, chasing missing information and updating a spreadsheet to show what had happened. When a supplier asked for an update, the requester often had no answer beyond, “I think it is with finance.”

There was also a governance gap. Approval decisions existed in email threads, sometimes with a revised attachment and sometimes without one. The business could not easily show who approved a request, when they approved it, or which value they had approved. That matters when spend controls are reviewed, but it also matters when teams simply need to make decisions quickly.

The initial request was familiar: could the process be automated? The better question was more specific: which manual steps should disappear, and which decisions still needed a person?

What the workflow automation case study set out to fix

The aim was not to automate every part of purchasing. A manager still needed to decide whether the request was justified. Finance still needed to check budgets and coding. The value came from removing administrative handling around those decisions.

The project had four practical objectives:

• give staff one clear place to submit a request;
• route each request to the right approver based on spend and department;
• provide an auditable record without a separate tracker; and
• notify people when they had an action, rather than relying on someone to chase them.

That distinction prevented a common mistake. Workflow projects can become over-designed when every exception is treated as a reason to build a new branch, form or rule. In this case, the process was standardised first. Exceptions were identified, but only the repeatable ones were built into the first release.

The solution: SharePoint, Power Apps and Power Automate

A SharePoint list became the central record for purchase requests. It held the essential fields: requester, department, supplier, amount, reason for spend, cost code, supporting documents and current status. The list was designed as the record of truth, not merely a trigger for emails.

A straightforward Power Apps form replaced the spreadsheet. It made required information clear at the point of submission and reduced incomplete requests. Staff could submit a request without needing to understand the approval logic behind it.

Power Automate then handled routing and notifications. A request below the agreed threshold went to the line manager. Higher-value requests moved through additional finance and director approvals. Each decision updated the SharePoint record, captured comments and recorded the time of approval or rejection.

The workflow also sent reminder notifications where an approval had not been actioned within the agreed period. Crucially, reminders did not just repeat the original email. They gave the approver a clear action and a link to the request record, so they could make a decision with the relevant detail in front of them.

A simple SharePoint page gave requesters and finance a view of live requests by status. This removed much of the “where is this up to?” traffic that had previously landed with the finance team.

Why the first version stayed deliberately simple

The project could have included budget-system integrations, supplier data validation and a separate approval route for every department. Those additions may be worthwhile in some organisations. They were not necessary to solve the immediate problem.

The first release focused on the part of the process causing the most friction: submitting, routing, deciding and recording requests. That meant the business could test the process with real users before investing in more complex work.

This is often the right trade-off for an SMB. A workflow that removes 70 per cent of the manual effort and is in use within weeks is normally more valuable than a fully specified system that takes months to reach launch. It also gives the organisation evidence for what to improve next, rather than assumptions gathered in a lengthy workshop.

There were boundaries. The workflow was not used for urgent emergency purchases, where a defined escalation route remained more appropriate. Nor did it try to make budget decisions automatically. Automation made the route visible and consistent; accountability for spend remained with the relevant people.

The result: fewer handoffs, clearer accountability

The immediate operational change was visibility. Employees could see the status of their requests without emailing finance. Approvers could see what was waiting for them. Finance had a single view of open, approved and rejected requests, with a record of each decision.

The reduction in manual handling was equally useful. The team no longer copied information from attachments into a tracker, searched through email chains to establish the latest position, or sent routine chaser messages one by one. That time was redirected towards checking the substance of requests rather than administering them.

Approval speed improved, though it is worth being precise about why. Automation did not make managers more available. It made outstanding actions harder to overlook and removed the pauses caused by unclear ownership. Where approvals still took time, the business could now see whether the delay was with the requester, manager, finance team or final approver.

The audit trail improved as a by-product of the design. Each request had one record, the relevant supporting documents and a time-stamped approval history. There was no need to reconstruct the story from several inboxes at month-end.

What made the project work

The technology was not the difficult part. The successful decisions were made before the workflow was built.

First, the organisation agreed its approval rules. This sounds obvious, but many processes contain unwritten assumptions: who covers for an absent manager, what happens when a request is amended, and whether an email reply counts as approval. Those points need decisions, not clever configuration.

Second, the request form was kept short. If staff need to complete twenty fields to request a modest purchase, they will find a workaround. The form captured what approvers genuinely needed and nothing more. Additional information could be requested where necessary.

Third, ownership was clear after launch. Finance owned the process rules, while the Microsoft 365 team owned the technical support and controlled changes to the workflow. Without that split, requests for small alterations can accumulate and users lose confidence in the system.

Finally, the process was reviewed after the first few weeks of use. The team looked at rejected requests, repeat questions and approvals taking longer than expected. One extra field was added to reduce follow-up queries, while an unused routing rule was removed. That is a far more useful improvement cycle than trying to predict every possible scenario upfront.

When workflow automation is worth doing

A process is a strong candidate for automation when it is repeated frequently, follows clear rules and creates a visible administrative burden. Approval requests, onboarding tasks, document reviews, policy acknowledgements and service requests often fit that description.

It is less suitable when every case is genuinely different, the underlying policy is unresolved, or staff are compensating for a deeper issue such as unclear authority. Automating confusion only makes it arrive faster.

For organisations already using Microsoft 365, SharePoint and Power Automate can provide a practical foundation without buying a separate workflow platform. ThePoint typically starts by mapping the current handoffs, identifying the points where work is being chased or rekeyed, and agreeing the smallest useful first release.

The useful closing thought is this: do not measure a workflow by how many steps it automates. Measure it by how much easier it makes it for the right person to take the next action, with the right information, at the right time.