The path
Agree the process first, then build the flow
patchley captures the process from the people who run it and agrees it as a BPMN 2.0 diagram with lanes, control steps and analyses per step. That agreed version is handed over as a document: the BPMN 2.0 XML file and a PowerPoint deck that carries the analyses per step. Your team reads it and builds the flow in Power Automate by hand.
Specification and build
What the diagram defines, what you configure in Power Automate
Each element of the agreed diagram answers a question the flow will ask. The left column is settled with the people in the workshop; the right column is your team's configuration work, named in general terms because every environment is set up differently.
| What the agreed diagram defines | What you configure in Power Automate | |
|---|---|---|
| Trigger | Start event named after what starts the case: a form submitted, an email received, a record created. | The trigger of the flow, and the data it arrives with. |
| Roles | Lanes for the roles that do the work, and the hand-overs between them. | Who acts: who is assigned a task, who is notified, who receives the approval request. |
| Decisions | Gateways named as questions, each outgoing flow labelled with an answer. | Conditions and branches: the fields and values that send the case one way or the other. |
| Data | Data objects and systems per task: what a step reads, what it produces, where it works. | Fields and records: the lists, tables or files the flow reads and writes, and the connectors to reach them. |
| Controls | Control steps marked: approvals, four-eyes checks, compliance reviews. | Approval actions that cannot be skipped, and what happens while the flow waits for them. |
| Exceptions | Paths and ends for the cases that are not the happy path: missing information, rejection, withdrawal, timeout. | Exception handling: the branch for each of those cases and the notification that goes with it. |
Before you build
Seven things to define, in order
The sequence below is the one that avoids rework. Steps one to five happen in patchley with the people who run the process; six is the hand-over; seven is the build.
Capture the As-Is from the people, not the handbook
A workshop, an interview or a meeting patchley joins. The result is the process as it runs today, with the workarounds and the exceptions that a flow has to handle.
Name the trigger and the roles
One start event named after what really starts the case, and lanes for roles, not departments. Every lane becomes a question in the build: who is assigned, who is notified, who approves.
Write every decision as a question with answers
"Amount above limit?" with "yes" and "no" is a condition a builder can configure. "Check amount" is not.
Mark the controls
Every approval and every check that must not be skipped is a control step in the diagram. These become the approval actions in the flow, and they are the ones an audit will ask about.
Decide the To-Be
Which steps stay with people, which the flow takes over, which an AI agent might take later. Designed as its own diagram with the As-Is one switch away, so that the difference is visible and agreed.
Hand over the specification
BPMN 2.0 XML and the PowerPoint deck that carries the analyses per step. The process owner's sign-off is on the version your team builds from.
Build the flow, and keep the diagram as the reference
Your team configures the flow. When the build changes the process, the change goes back to the diagram and to the people who agreed it.
patchley does not import into Power Automate and does not connect to it. The agreed process is a document your team builds from. That keeps the specification independent of the platform, and the flow independent of patchley.