Capstone: automate one real process end to end

What this capstone asks of you

Everything so far has been practice on parts. This asks you to deliver a whole: one real recurring process, automated end to end, built to be left running. The bar isn't "it worked when I demoed it". The bar is "I'd be comfortable it runs next month while I'm on leave, because it alerts me if it breaks, it handles the messy cases, and a person still checks the one step that matters."

Three things separate a power-user flow from a beginner's:

• It's whole. It goes from trigger to finished outcome, not "the first two steps of a good idea".
• It survives reality. It has failure alerts, handles the obvious things that go wrong, and doesn't silently drop work.
• It's measured. You can say what it saves in a sentence backed by a rough, honest number, not a feeling.

Get those three right on one modest process and you've demonstrated the whole level.

Choosing the process

Pick something repeated, measurable, low-risk and yours to change: the same test as any good automation candidate. Weekly at least, so there's a real payback. Something you can time or count, so you can measure it. Nothing that could hurt anyone if the pilot misfires, and nothing that sends externally or touches confidential data without a human check. And a process you actually have the standing to change, so the flow can become real practice rather than a toy.

If you've nothing suitable to hand, use the Fernway world. Two strong options, both drawn from the earlier lessons:

• The customer-feedback pipeline from the project brief: an email arrives in the feedback mailbox, an AI step classifies it, it's logged to a shared list, and it's routed to the right person: Billing to Dan, Technical to Ravi, anything unclear to Maya, and nothing replies to a customer without a person.
• Dan's expenses process from the meeting notes: a claim is submitted on the form, it's logged, claims over £500 go to an approver, both outcomes tell the claimant, and Finance gets a tidy record.

Either is a genuine recurring process with a real judgement, a real routing decision and a real risk to guard: exactly the right size for a capstone.

The project brief

The one-page write-up

Copy this and fill it in. Keep it to a page; a power user communicates impact briefly.

Capstone write-up

• Process: the task, in one line
• Who does it / how often: e.g. Maya, every working day
• The problem with the old way: slow, inconsistent, things missed; be specific
• Baseline: time and/or quality before, measured once, e.g. 6 min per item, some never logged
• The flow, in three lines: trigger, the main steps, where it finishes
• Error handling: what happens on a missing field, an unexpected case, a failed step
• Where the human still checks: the load-bearing step you deliberately kept for a person
• Reliability: failure alerts on? second owner? which account runs the connections?
• New per-item result: time and/or quality after, e.g. under 1 min, every item logged
• What this saves (one paragraph): see below
• Limits and next step: what could still go wrong, and whether you'd widen it, keep it or park it

The "what this saves" paragraph

Write one honest paragraph. Name the baseline, the new figure, the saving per item, and what it scales to over a week, month or year, with your working shown. Rough is fine; honest and shown beats big and vague. For example: "Logging and routing a feedback email by hand took Maya about six minutes, and a few slipped through unlogged each week. The flow does it in under one, and nothing is missed. At roughly 15 items a week that's about 75 minutes saved weekly, call it 55 hours a year, plus the harder-to-count gain of no feedback going unanswered. It took about three hours to build and half an hour to make reliable, so it pays that back inside a month." That paragraph, more than the flow itself, is what makes the case to a manager.

Suggested approach

Build in the order above and resist two temptations. The first is skipping the baseline because you're keen to build, but without the "before" figure you can never prove the "after", and an unmeasured capstone is a basic-level result however slick the flow. The second is over-scoping: one process, automated properly, beats three half-built ones. If mid-build you find yourself adding a fourth feature, stop and ship the three that work.

Be honest about setup cost in your paragraph. A flow that saves an hour a week but took four hours to build and reliability-proof still pays back inside a month, and saying so is far more credible than pretending it was free. And keep the human check visible in the write-up, not hidden: "a person approves any reply before it sends" is a design strength, not an admission the flow is incomplete.

Self-assessment rubric

Score yourself honestly, and aim to point at evidence for your score.

• Basic. You automated a real recurring process and it works on the normal case. But it has no failure alerts, little or no error handling, or no baseline, so if an odd input arrives or a step breaks, you'd find out from a colleague, and you can only describe the saving as a feeling ("it feels quicker").
• Good. The flow runs end to end, handles the obvious failure cases and has an explicit fallback branch, alerts you when it breaks, and keeps a human on the risky step. You set a baseline, ran it several times including an awkward input, and your "what this saves" paragraph gives a real per-item saving with honest working.
• Excellent. All of "good", plus: it's co-owned and you can account for every connection and what it touches; you tested the error paths deliberately, not just the happy one; your saving scales to a credible annual figure with setup cost stated; you can answer IT's governance questions; and you've named a concrete next step. Someone reading your one-pager could adopt the flow, or take it to IT, and act on it as it stands.

The gap between "good" and "excellent" is almost entirely error handling, governance and honest measurement, not a cleverer flow.

Evidence note

Common mistakes

• Building the happy path and calling it done. A flow that only works when every input is perfect isn't finished; real inputs are messy. The error handling and the fallback branch are the capstone, not an optional extra.
• Skipping the baseline. Without a "before" figure measured first, you can't prove the improvement, and the whole thing drops to a basic-level result. Measure once, the old way, before you touch anything.
• No failure alert on a flow you'll leave running. An automation you can't see failing isn't reliable; it's a silent outage waiting to happen. Turn the alert on before you rely on it.
• Removing the human from the risky step. The most damaging mistake, and the most tempting once the flow has run cleanly a few times: letting it send, spend or delete unsupervised because it "always works". A few good runs earn a wider trial, not the removal of the check. Keep a person on anything irreversible and say so.
• Over-trusting the flow because the demo went well. A capstone that impresses in a five-minute demo can still fail quietly in week three when a connection expires or an unexpected input arrives. The power-user standard isn't "it worked when I showed it"; it's "it tells me when it breaks, handles what I didn't foresee, and keeps a human on the part that matters". Build for the month you're not watching, not the demo you are.

Keeping current

The specific menus (where failure alerts live, how error handling is configured, how ownership and environments work) will keep shifting, so re-check them against Microsoft's error handling guidance on Microsoft Learn when you build. The capstone method is durable, though, and outlasts every menu: pick a real recurring process, baseline it, automate it whole, make it survive reality, keep a human on the risk, and prove the saving with an honest number. That discipline is what makes you a power user rather than someone who once built a flow. Accurate as of 13 July 2026.