From process map to automation specification

Reference the validated map version and record its trigger, completion evidence, owner, actors, systems and excluded work. Define every status and decision term in operational language. A specification should not quietly redesign the process; unresolved policy questions return to the owner with options. Mark future-state changes explicitly and explain who approved them. Include assumptions, dependencies and out-of-scope requests. This baseline lets builders ask precise questions and prevents the same label, such as ‘approved’ or ‘complete’, from carrying different meanings across teams or applications.

For every step, name the initiating event, preconditions, source system, permitted fields, transformation rules, destination and success response. Define formats, required values, valid ranges and handling of missing or duplicated identifiers. Use synthetic examples in documentation, never real customer or confidential records. State which fields must not move. Distinguish creation from update and identify the stable key used to avoid duplicate actions. If a connector cannot provide reliable event identity or completion confirmation, record that limitation before implementation rather than assuming a clean happy path.

Turn each rule into a controlled example with initial state, event, expected field changes, prohibited changes, notification and retained evidence. Include normal, boundary, invalid, duplicate, out-of-order and downstream-failure cases. Confirm that communication occurs only after the required write succeeds and that manual fallback does not create duplicates when automation resumes. Define security and privacy checks proportionately with responsible specialists. Acceptance is about observable behaviour, not whether the workflow ran without displaying an error. Give each test an owner and preserve results with the specification version.