Prompt templates that turn a rambling process description into a first-draft Power Automate flow

Background

The usual way into a new Power Automate flow is to open a blank canvas and start adding actions as you think of them - a trigger, a condition, maybe an approval, then a fix for the thing you forgot, then another. It works, but it means the shape of the flow gets discovered live, inside the tool, one step at a time, with no chance to spot a missing error branch or a duplicated condition until it's already wired in.

The better order is to describe the process in plain English first - to an AI tool, not the canvas - and ask for the flow's design: trigger, each action in sequence, every condition and its branches, and where it needs an error path. You still build it yourself, action by action, in Power Automate. What the model gives you is a checklist to build against, not a flow to import and trust - there's no reliable way to hand it a live connection to your tenant, and you wouldn't want to even if there were. What you get instead is a design that's had its gaps found on paper, where they're free to fix, rather than found three months into production.

Setup

The shape that gets you a usable design, not a vague summary:

• Role - a flow designer thinking in triggers, actions and branches, not a general "how do I automate this" assistant.
• Context - what you'll hand over (a real, possibly messy process description) and what you want back (a numbered flow design, not prose).
• Inputs - the actual process: the trigger, the systems involved, the steps as you know them, and anything that already goes wrong today.
• Task - the specific shape: number every action, mark every decision point and its branches, and give the error path its own numbered step rather than a footnote.
• Constraints - the failure modes to rule out: no step that silently assumes success, no branch left unlabelled, nothing that needs a connector or licence tier you haven't confirmed you have.

Standard automation design

For a process that's mostly linear with one or two decision points:

You're designing a Power Automate flow from a plain-English process
description. You will not build or deploy anything - just produce the
design a human builds from.

Context: I'll describe a real manual or semi-manual process. Return a
numbered flow design: trigger, then each action in order, with every
decision point shown as a branch and every branch labelled.

Inputs:
- Trigger: [e.g. A FORM SUBMISSION, A SCHEDULED TIME, A FILE LANDING IN A
  FOLDER]
- Systems/connectors involved: [e.g. SHAREPOINT, OUTLOOK, A SQL TABLE]
- Steps as you currently understand them, in any order: [LIST]
- Decision points: [e.g. AMOUNT OVER A THRESHOLD? APPROVED OR NOT?]
- What currently goes wrong, if anything: [DESCRIBE]

Task: number every action. For each decision point, show both branches and
where each one rejoins the flow or ends it. Add an explicit error-handling
step - what happens if a connector call fails - even though I didn't ask
for one; that step is not optional.

Constraints: no step that assumes an action succeeded without a check. No
branch that dead-ends without reaching either a completion state or a
flagged failure state. Flag anywhere the design depends on a connector,
licence tier, or permission you haven't confirmed exists in this tenant.

Retrofit design - documenting a flow that already exists but was never designed

For the flow someone built two years ago by trial and error, that nobody has a clean description of any more:

You're reverse-engineering a flow design from how a process actually
behaves today, warts included.

Context: I'll describe what currently happens, including the workarounds
people have built around it. Return the design as it actually runs today,
not the design it should have been - a second, separate section can note
what you'd change.

Inputs:
- What triggers it today, as best anyone knows: [DESCRIBE]
- What it does, including manual steps people do around it: [LIST]
- Known failure points or things people quietly work around: [LIST]

Task: document the flow as it actually behaves, workarounds included, as a
numbered design. Then, as a clearly separate section, list what you'd
change if rebuilding it from scratch and why each change matters.

Constraints: don't blend "what it does" and "what it should do" into one
list - a workaround someone still depends on today needs documenting
before it can be safely removed, not silently dropped from step one.

Approval-gated automation

For anything where an automated action needs a human sign-off before it actually does something to real data:

You're designing an automation with a mandatory human approval step before
any state-changing action.

Context: return a flow design where nothing that changes data, sends
externally, or spends money happens without an explicit approval step
first.

Inputs:
- What the automation does once approved: [DESCRIBE]
- Who approves, and on what basis: [ROLE AND CRITERIA]
- What happens on rejection: [DESCRIBE]
- Timeout behaviour if nobody responds: [DESCRIBE, OR ASK ME WHAT I WANT]

Task: trigger, data-gathering steps, an explicit approval step naming who
approves it, an approved branch, a rejected branch, and a timeout branch
if none is specified - ask rather than assume one.

Constraints: the approval step is not decorative - nothing after it should
be reachable on any path that skips it. Flag if the described process has
a way around the approval that isn't obviously intentional.

Multi-system handoff automation

For a flow whose whole job is moving data or a state change between two or more systems that don't otherwise talk to each other:

You're designing a flow whose job is a handoff between systems that don't
share data any other way.

Context: return a flow design that makes the handoff itself, and what
happens if one side is unreachable, the most visible part of the design.

Inputs:
- Source system and what changes there: [DESCRIBE]
- Destination system and what it needs to receive: [DESCRIBE]
- What "success" means on both sides: [DESCRIBE]
- What should happen if the destination is unreachable: [DESCRIBE, OR ASK]

Task: source trigger, a transformation step naming exactly what fields map
where, the write to the destination, a verification step that actually
checks the write succeeded rather than assuming it, and a retry or alert
path if it didn't.

Constraints: never treat "the API call didn't error" as the same thing as
"the record now exists correctly on the other side" - ask for an explicit
verification step, not just error-catching on the call itself.