Phase 5 · Power Automate · Level 1 · Foundations
Early automation mistakes, and how to avoid them
By the end, you'll be able to…
- Spot the three pitfalls that trip up almost every new flow builder
- Put simple guardrails in place: notifications, testing and small builds
- Treat a flow's output as something to check, not something to trust blindly
Why it matters
The failures that catch out new flow builders are predictable: silent breakages, over-ambitious first builds, and skipping the test. Knowing them in advance turns each from a nasty surprise into a five-minute fix. This lesson names the traps and gives you the small habits that keep your flows honest.
Why flows go wrong quietly
The unnerving thing about automation is that it works out of sight. A flow you built and forgot can keep running (or stop running) for weeks without a word. When a person forgets a task, they usually notice eventually. When a flow fails, nothing happens, and nothing happening is exactly what a broken flow looks like too. So the mistakes below aren't about clumsy building; they're about the blind spots that come from work happening where you can't see it.
Let's carry one Fernway example through. Dan in Finance builds a flow: when an expense email with a receipt arrives, save the receipt to a "Receipts" folder and log the amount in a spreadsheet. It's a good candidate: frequent, fiddly, easy to forget. Here's how it can still go wrong, and how to stop each one.
Pitfall 1: The flow that fails silently
Three weeks in, Dan's connection to Outlook expires after an IT password reset. The flow stops. No receipts are saved. Dan doesn't find out until month-end, when half the receipts are missing, and by then they're scattered across an inbox he thought was being emptied for him.
The trap is assuming no news is good news. With automation it's the opposite: no news might mean it's working, or it might mean it died silently.
Guardrails:
- Turn on failure notifications so Power Automate emails you the moment a flow fails. This is the single highest-value habit in the whole phase.
- Glance at the flow's run history (the list of every run with a tick or a cross) now and then, especially in the first couple of weeks.
- After any password change or IT update, check your connections still work.
If any step in this flow fails, send me an Outlook email with the flow name and the error so I find out straight away instead of weeks later.
Why this works: A plain-English request to notify you on failure gets Copilot to add the 'configure run after / send on failure' pattern without you hunting for the setting. Naming both the trigger (a failure) and the action (email me) is what makes it buildable.
Pitfall 2: The over-complex first build
Flushed with success after one working flow, it's tempting to build a monster: save the receipt, log it, categorise it, email the manager, update three spreadsheets, and branch differently for every supplier, all in one go. Then it doesn't work, and because there are fifteen steps and four conditions, you've no idea which part is broken.
Complexity isn't impressive; it's just harder to test and harder to fix. A flow you don't fully understand is a liability, however clever it looks.
Guardrails:
- Start small and grow in tested stages. Get "save the receipt" working and trusted. Then add "log the amount" and test again. Then the next step. Each addition is a small, checkable change.
- Prefer two simple flows over one tangled one where the jobs are really separate.
- If a flow needs a branch ("if the amount is over £500, ask for approval"), add it only once the straight-through path works.
Take my working "save receipt" flow and add just one step: after the file is saved, add a row to the "Expenses log" Excel file with today's date and the sender's name. Don't change anything else.
Why this works: Asking Copilot for one incremental step on top of a working flow keeps the build small and testable. It mirrors the 'small tested stages' habit and makes any failure easy to locate.
Pitfall 3: Not testing (or testing once and walking away)
The commonest mistake of all: building a flow, seeing it look right in the builder, switching it on, and moving on. A flow that reads correctly can still fail on real data: an unusual attachment type, an empty field, a folder that doesn't exist. And a flow that passed one test in January can quietly break in March.
Guardrails:
- Always run a real test with real-shaped input before you rely on a flow; for Dan, an actual receipt email, not just a glance at the steps.
- Test the awkward cases too: an email with two attachments, or none, or an odd file type.
- Re-check occasionally. One green test proves it can work, not that it always will.
- Confirm the actual result, not just the green ticks: open the folder and see the file; open the spreadsheet and see the row.
List the things that could make this expense-saving flow fail or behave unexpectedly, and tell me what test email I should send to check each one.
Why this works: Getting Copilot to list what could break turns testing from a vague intention into a checklist. It surfaces edge cases (no attachment, multiple files, wrong type) you might not think to try.
The quiet fourth pitfall: over-trusting the flow
Underneath all three is the same error of judgement: trusting a flow more than you've earned the right to. A flow is fast and tireless, and that fluency is easy to mistake for reliability. But a flow only ever does exactly what you built, on exactly the data it meets, with none of the "hang on, that looks wrong" instinct a person brings. It will cheerfully file every receipt into the wrong folder, or log the wrong amount, at full speed, and never once doubt itself.
This matters even more now that Copilot can build flows for you from a sentence. A flow you described in plain English and never read is doubly unchecked; you didn't build it and you didn't verify it. Copilot writes a draft, exactly like any AI tool: it can misread you, pick the wrong connector, or leave a field blank. Read every step it produces and test it before you rely on it; the same "check the draft" rule from the earlier phases applies to flows.
The mindset to keep: automation removes the doing, not the responsibility. Whatever a flow does still has your name on it. Build small, test properly, get told when it fails, and check its output, and a flow becomes something you can trust, because you've earned the trust rather than assumed it.
Try it now
Common mistakes
- Assuming silence means success. A silent flow may be working or may be dead. Failure notifications and the odd look at run history are how you tell the two apart.
- Building big before building small. A fifteen-step first flow is fifteen places for a bug to hide. Grow in tested stages so you always know what changed.
- Testing once and never again. One passing test proves the flow can work today, not that it always will. Re-check occasionally, especially after account or password changes.
- Over-trusting a flow, or a Copilot draft, you never checked. A flow does exactly what it was built to do, at speed, with no instinct for when that's wrong. Read it, test it, and keep an eye on its output; the responsibility for what it does stays with you.
Keeping current
The pitfalls here are durable (they come from how automation works, not from any one release) but the exact place to switch on failure notifications moves with portal updates. For Microsoft's current guidance on monitoring and fixing flows, see Troubleshoot and monitor flows on Microsoft Learn. Accurate as of 13 July 2026.