Phase 5 · Power Automate · Level 2 · Practitioner
Copilot in Power Automate: describe, then check
By the end, you'll be able to…
- Describe a flow to Copilot in plain English clearly enough to get a close first draft
- Read a Copilot-generated flow step by step and judge whether it's right
- Spot and correct the four things Copilot most often gets wrong
Why it matters
Copilot can turn a sentence into a working-looking flow in seconds, which is both useful and risky. The risk isn't that Copilot builds nonsense; it's that it builds something plausible that's subtly wrong, and you switch it on without checking. The real skill this lesson teaches is not describing a flow. It's reading the one Copilot gives you back, because a flow you can't read is a flow you can't trust.
Why reading beats describing
Describing a flow to Copilot is the easy half. You type "when a form is submitted, save it to a spreadsheet and tell the team", and in a few seconds Copilot assembles a trigger and some actions and drops connections in for you. It feels like magic, and for simple flows it's often close to right.
The hard half, the half that actually matters, is reading what came back and deciding whether it's correct. Everything you learned building flows by hand in Level 1 and the last two lessons was really preparation for this moment: you know what a trigger is, what an action is, what dynamic content does, so you can look at Copilot's draft and say "that trigger is wrong" or "it never fetched the response details". Someone who can only describe flows but can't read them is stuck trusting a tool that is confidently wrong a fair amount of the time. Someone who can read them gets Copilot's speed and keeps the judgement. That's the whole game.
We'll carry one Fernway job through: Dan in Finance wants "when an expense form is submitted, save it to the expenses spreadsheet and post in the Finance channel".
Step 1: Describe it well
You reach Copilot either from Create (the "Describe it to design it" entry point) or from the Copilot pane inside the flow designer. Either way, a good description gives Copilot the same things a good prompt always gives a model: the trigger, the actions, the apps, and the key details. Vague in, vague out.
When someone submits the "Expense Claim" form, save the claimant's name, the amount and the date to the "Expenses" table in the Finance-Log.xlsx workbook, then post a message in the Finance team's "Claims" channel saying a new claim was submitted and by whom.
Why this works: This names the trigger (expense form submitted), both destinations (the named Excel table and the Finance Teams channel) and the fields to save, so Copilot has a concrete target. A description this specific produces a draft close enough that checking it is quick. The point of a good prompt is to make verification easy.
The representative result is a flow with four steps: a Forms trigger, an Excel "add a row" action, and a Teams "post message" action, and, if Copilot got it right, a "Get response details" step in between. Whether that middle step is there is the first thing you'll check.
Step 2: Read it step by step
Now the real work. Go through the generated flow one step at a time, out loud if it helps, asking of each step: what app is this, is it a trigger or an action, and is it the right one? Then check the joins: does each field draw from the right dynamic content? You are looking for four specific kinds of error, because Copilot makes the same ones repeatedly.
1. The wrong trigger
Copilot sometimes picks a plausible-but-wrong trigger: a manual "button" trigger when you wanted an automatic one, or "when a file is created" when you meant "when a form is submitted". Check the very first step names the event you actually described. A flow with the wrong trigger never fires when you expect.
2. A missing intermediate step
The classic is the Forms pipeline with no Get response details step, so the Excel row fills with blanks, exactly as in Lesson 1. Copilot often jumps straight from trigger to "add a row" and skips the fetch. If the answers need retrieving before use, make sure the retrieving step is there.
You've gone straight from the form trigger to adding the row, but the trigger only gives the response ID. Add a "Get response details" step first, then map the name, amount and date from those details into the table.
Why this works: Rather than rebuilding, you correct the specific gap in plain English. Naming the missing step ('get the full response details' before the row is added) is precise feedback Copilot can act on, the same 'iterate, don't start over' habit from prompting, applied to a flow.
3. Wrongly mapped fields
Even with the right steps, Copilot can wire the wrong dynamic content into a field, putting the date where the amount goes, or the response ID where the name should be. Open each action and read what feeds each field. This is the error most likely to survive a casual glance, because the flow runs fine; it just saves the wrong things in the wrong columns.
4. Invented or guessed details
Copilot fills gaps confidently. If your description didn't name the exact channel, table or folder, Copilot picks one, and it may be plausible but wrong. Check every location: the right file, the right worksheet, the right channel. A hallucination in a flow looks like a real-but-wrong file name, not obvious gibberish.
Step 3: Correct, then test
You correct a Copilot flow the way you iterate on any AI draft: with specific feedback, not a fresh start. Tell it the one thing that's wrong ("the trigger should be a form submission, not a button"), or fix the field by hand in the designer, whichever is faster. Then, crucially, you test it exactly as if you'd built it yourself, because you might as well have: a flow is a flow, and Copilot's involvement changes nothing about your responsibility for what it does. Submit a real test entry, watch the run, and confirm the actual result (the right row, the right message), not just green ticks.
The message is posting to the "General" channel, but it should post to the "Claims" channel in the Finance team. Change only the destination channel and leave the rest of the flow as it is.
Why this works: This is targeted correction of an invented detail: Copilot guessed a channel, and you name the right one. Precise, one-change feedback keeps everything else Copilot got right, which is faster and safer than regenerating the whole flow from scratch.
Try it now
Common mistakes
- Switching on a Copilot flow without reading it. A flow you described but never checked is doubly unverified; you didn't build it and you didn't test it. Read every step before it runs.
- Assuming green ticks mean correct. A mis-mapped field runs perfectly and saves the wrong data. Ticks prove the flow ran, not that it did the right thing; open the result and check.
- Regenerating instead of correcting. Throwing the whole flow away and re-describing loses the parts Copilot got right and often reintroduces the same error. Fix the one wrong step with specific feedback.
- Over-trusting Copilot because it sounds confident. Copilot presents a guessed channel or an invented file name with exactly the same assurance as a correct one. Fluency is not accuracy. Treat every location, trigger and mapping as a claim to verify, especially the details you didn't spell out. The tool drafts; the responsibility for what the flow does stays entirely with you.
Keeping current
Copilot in Power Automate changes quickly; entry points, phrasing and capabilities all move. Microsoft's Create your first cloud flow using Copilot and Get the most from Copilot in the designer on Microsoft Learn track the current experience. The read-and-check discipline, though, is durable, and it will matter more as Copilot does more. Accurate as of 13 July 2026.