Phase 5 · Power Automate
Power Automate prompt library
Why it matters
Copilot in Power Automate turns a plain-English description into a working-looking flow, but only if your description is specific enough to hit. This is a set of copy-ready descriptions you can paste into Copilot to draft real, useful flows, plus a handful of expressions that solve the fiddly bits Copilot often gets wrong. Treat every draft the way you learned to: read it step by step, check the triggers and mappings, and test it before you trust it. A good description makes that checking quick; it doesn't remove it.
How to use this library
Each card below is either a flow description to paste into Copilot in Power Automate (from the Create "describe it to design it" box, or the Copilot pane in the designer) or an expression to drop into a field. The descriptions name the trigger, the actions, the apps and the key details, because a vague description gets a vague flow, and the specific ones here give Copilot a real target to hit.
Two rules apply to everything here. First, Copilot drafts; you verify. Read every generated flow step by step, check the trigger is right, the intermediate steps are present, and each field maps to the right dynamic content, then test it with realistic data before switching it on. Second, keep the Phase 0 privacy rules: don't wire real customer or personal data through a personal or trial environment while you're testing. The examples use the fictional Fernway Group so you can practise safely.
Names in [square brackets] are placeholders: swap in your own mailbox, list, channel or column names before pasting.
Email & files
When a new email arrives in the [Invoices] mailbox that has an attachment, save each attachment to the [Finance/Invoices] folder in SharePoint, using the sender's name and the date received in the file name. Only run when there is at least one real attachment.
Why this works: It names the trigger (a new email with an attachment), the filter (only from a mailbox and only real attachments), and the exact destination, so Copilot doesn't guess where files should land. Naming 'only if it has an attachment' stops the flow firing pointlessly on every email.
When a new email arrives in the [Support] mailbox, check whether the subject line contains the word "urgent". If it does, move it to the [Urgent] folder and post a message in the [Support] Teams channel. If it does not, just move it to the [Triage] folder.
Why this works: A plain keyword rule needs no AI and never hallucinates, so the description asks for a simple condition on the subject line. Spelling out the 'otherwise' path means nothing is silently dropped, a common gap in Copilot drafts.
Every Friday at 4pm, list all files added to or changed in the [Team Documents] SharePoint library in the past seven days, and send me one summary email listing each file's name and the date it was modified. If nothing changed, send an email saying so.
Why this works: It names the schedule, the source, the time window and the output shape (a single summary email), so Copilot builds a recurrence trigger rather than an event one. Asking for one email 'listing name and modified date' pins the format down.
When a new email arrives in the [Feedback] mailbox, use AI to classify the body as Billing, Technical, Praise or Other. Add a row to the [Feedback Log] SharePoint list with the sender, subject, category and date. Then notify [Dan] for Billing, [Ravi] for Technical, log Praise with no notification, and notify [Maya] for anything else. Never send a reply to the customer automatically.
Why this works: This is the one place AI earns its keep: a judgement that can't be a keyword rule. It names a closed set of categories, an explicit fallback branch, and a hard rule that nothing replies to a customer automatically, so the risky step stays with a person.
Approvals
When a request is submitted on the [Leave Request] form, start and wait for an approval from [the requester's manager]. If approved, record it in the [Leave] SharePoint list and email the requester to confirm. If rejected, email the requester to say it wasn't approved and why. Handle both outcomes.
Why this works: Copilot often builds the 'approved' path and leaves 'rejected' empty. Naming what happens on both outcomes (including telling the requester when it's a no) closes the gap that otherwise leaves people guessing.
When an expense claim is submitted on the [Expenses] form, log it to the [Expenses] SharePoint list. If the amount is over £500, start and wait for approval from [Dan]. Send a reminder if there's no response within two working days, and escalate to [Priya] if there's still no response after four. Tell the claimant the outcome either way.
Why this works: It routes only the cases that need sign-off (over a value) and, crucially, asks for a reminder and an escalation so an approval can't stall forever waiting on someone who's away: the classic silent-hang failure.
When a new supplier is added to the [New Suppliers] SharePoint list with status "Pending", start and wait for approval from [Finance]. If approved, set the item's status to "Active" and post in the [Finance] Teams channel naming the supplier. If rejected, set the status to "Declined" and note who rejected it.
Why this works: It ties the approval outcome to concrete follow-through (updating a record and posting to a channel) so the decision doesn't just sit in an inbox. Naming the exact list and channel stops Copilot inventing a plausible-but-wrong destination.
Data & Excel
When a new response is submitted to the [Site Visit] Microsoft Form, get the full response details, then add a row to the [Visits] table in the [Site-Log.xlsx] workbook with the visitor's name, the site, the date and their comments. The workbook has a real Excel table created with Insert > Table.
Why this works: It names the 'get response details' need implicitly by asking for the actual answers, and names a real Excel table, the two things Copilot most often skips, which cause blank rows and 'table not found' errors. Reminding it the sheet must be a proper table heads off the top Excel failure.
When a new item is created in the [Enquiries] SharePoint list, add a matching row to the [Enquiries Summary] list copying the customer name, the enquiry type and the date, and set the summary item's status to "New". Only copy items where the enquiry type is filled in.
Why this works: It picks SharePoint-to-SharePoint (structured records, no 'format as a table' pitfall) and names the exact fields to copy, so Copilot maps columns rather than guessing. Naming the trigger as 'when an item is created' keeps it event-driven.
Every weekday at 8am, count the rows added to the [Orders] SharePoint list in the past 24 hours. If the count is zero, email [Maya] to flag that no orders came through yesterday, since that usually means something upstream has broken. Otherwise do nothing.
Why this works: It turns a scheduled recurrence into a simple data-quality check and asks for an alert only when something looks off, so you're not spammed daily. This is the 'make it tell you' habit applied to data rather than failures.
Notifications
When a new item is added to the [Feedback Log] SharePoint list, post a message in the [Operations] team's [Feedback] channel with the customer name, the category and a link to the item, so whoever's on duty can pick it up.
Why this works: It names the exact team and channel and the fields to include, so the message is useful and lands in the right place. Vague 'tell the team' descriptions make Copilot guess the channel, a guess that runs fine while going to the wrong place.
Send me a Teams message whenever the [Feedback Routing] flow fails, including which step failed and the error message, so I find out from the flow rather than from a colleague. Do not send anything when it succeeds.
Why this works: This is the reliability habit as a description: a flow that tells you when it breaks. Asking for the failed step's name and error in the alert turns a silent outage into a same-day fix with a head start on the cause.
Every morning, check the [Actions] SharePoint list for any item whose due date is two working days away and whose status is not "Done", and send the item's owner a Teams message reminding them, with the action and the due date. Skip anything already marked Done.
Why this works: It reads a due date from a record and messages ahead of time, naming the window (two days before) so the reminder is timely, not late. Asking it to skip completed items stops nagging about things already done.
Expressions
formatDateTime(utcNow(), 'dd/MM/yyyy')
Why this works: Capital MM is the month; lowercase mm is minutes, the single most common date bug. This expression uses the correct casing to print a proper dd/MM/yyyy date rather than quietly showing the minutes where the month should be.
formatDateTime(addDays(utcNow(), -7), 'yyyy-MM-dd')
Why this works: addDays with a negative number steps backwards from now, and yyyy-MM-dd is the safe sortable format for filtering. Useful for 'items changed in the last week' queries where a plain date comparison is needed.
coalesce(triggerBody()?['customerName'], 'Not stated')
Why this works: coalesce returns the first value that isn't null, so a missing field becomes a clean 'Not stated' instead of a blank or an error downstream. This is the honest-missing-field habit expressed in one function; swap in your own field reference.
toLower(trim(triggerBody()?['emailAddress']))
Why this works: trim removes stray leading and trailing spaces that break comparisons and look untidy in a log; toLower makes text easy to compare consistently. Nest them to clean and normalise a field in one step before you match or store it.
length(outputs('Get_items')?['body/value'])Why this works: length on the value array tells you how many records came back, so you can branch on 'did we find anything', the basis of the daily-health-check pattern. Point it at the output of your own 'Get items' or 'List rows' step.
if(greater(triggerBody()?['amount'], 500), 'High', 'Standard')
Why this works: A single if with greater returns a ready-made label you can write straight into a column or message, so 'over £500' becomes a plain 'High' or 'Standard' without a separate branch. Replace the field reference and the threshold with your own.