The path
Agree the process first, then build it in ServiceNow
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 workflow in ServiceNow by hand.
Specification and build
What the diagram defines, what you configure in ServiceNow
Each element of the agreed diagram answers a question the build 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 ServiceNow instance is set up differently.
| What the agreed diagram defines | What you configure in ServiceNow | |
|---|---|---|
| Roles | Lanes for the roles that do the work, and the hand-overs between them. | Who acts: assignment to groups and users at each step, and who is notified at a hand-over. |
| Decisions | Gateways named as questions, each outgoing flow labelled with an answer. | Conditions: the fields and values that route a record 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: which table holds the case, which fields are mandatory at which step. |
| Controls | Control steps marked: approvals, four-eyes checks, compliance reviews. | Approval steps that cannot be skipped, and who may approve. |
| Exceptions | Paths and ends for the cases that are not the happy path: missing information, rejection, withdrawal. | Exception handling: what happens to the record on each of those paths. |
| Documentation | Analyses per step: SOP, pain points, compliance, figures. | Help text, knowledge articles and the acceptance criteria for the build. |
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 build has to handle.
Name the roles as lanes
Roles, not departments. Every lane becomes a question in the build: who is assigned, who is notified, who may approve.
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 steps in the workflow, and they are the ones an audit will ask about.
Decide the To-Be
Which steps stay with people, which the workflow 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 in ServiceNow, and keep the diagram as the reference
Your team configures the workflow. 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 ServiceNow 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 build independent of patchley.