Error Handling
Part of Workflow testing and deployment
Comparing workflow versions before release
Compare workflow triggers, decisions, data, actions and recovery settings, including configuration outside a platform's version view.
Compare the proposed workflow with the version receiving live work, then check configuration that a version view may omit. The review should identify which inputs enter, which route they take, what is written and how failures are handled.
Identify the two versions
Record the live version identifier and an exact saved release candidate. Note each version's environment, connection identities and relevant configuration values. Identical definitions can produce different results when a destination URL or account differs.
Write the intended change in one sentence. Inspect every difference between the two versions, including edits outside that change. A retry setting or recipient may matter even when the requested edit concerns one branch.
Review Process for Workflow Version Comparison
- Identify live version and release candidateRecord version identifiers, environment, connection identities and configuration values.
- Define the intended changeWrite one sentence describing the proposed change.
- Inspect all differencesCheck edits outside the main change—e.g., retry settings, recipients.
- Trace material differencesAssess expected business impact and test cases for each difference.
- Validate in safe environmentTest both changed and unaffected routes before release.
Trace each material difference
Compare / Question to answer
- Intake
- Did the trigger, event filter or schedule change?
- Decisions
- Did a condition, default route or evaluation order change?
- Data
- Did a field path, transformation or required-value rule change?
- Effects
- Did the operation, connection, recipient or write payload change?
- Recovery
- Did timeout, retry, exception or notification behaviour change?
For each material difference, record its expected business consequence and a case that could reveal a mistake. If a branch was removed, trace its former inputs. If a field was renamed, follow its value into the destination action rather than judging the edit by its label.
Key Differences Between Workflow Versions
- Intake
- Trigger, event filter or schedule change?
- Decisions
- Condition, default route or evaluation order change?
- Data
- Field path, transformation or required-value rule change?
- Effects
- Operation, connection, recipient or write payload change?
- Recovery
- Timeout, retry, exception or notification behaviour change?
Use version history within its limits
Power Automate for desktop version control lets users save drafts, publish stable versions and restore previous versions. When enabled, versions are stored in Dataverse and can be accessed through the version history pane in the designer.
The feature is being rolled out gradually, so check whether it is available in the environment.
For any editor, identify the exact published version and draft being reviewed. Inspect configuration directly where the version history does not show the details needed for the comparison.
AWS Step Functions versions are immutable snapshots, and an alias can route new executions to a selected version. An execution started with an unqualified state-machine ARN uses the latest revision instead of the version selected by an alias. Review how callers start the workflow as well as the version definition.
Record the release decision
Attach the version identifiers, intended change, material differences, configuration review and proposed cases to the release record. Check a changed route and an unaffected route in a safe environment, recording observations only after testing. A visual diff does not establish an execution result.
Hold the release if the team cannot identify which version new work will use, where a changed connection points, or how to recover from a changed external effect.
Pre-Release Workflow Verification Checklist
- Attach version identifiers and intended changeInclude release candidate and live version details.
- Document material differencesList all changes across intake, decisions, data, effects, recovery.
- Review configuration not visible in version historyInspect direct settings where version views are incomplete.
- Test changed and unaffected routesRun tests in a safe environment; record observations.
- Hold release if uncertainIf unclear which version will process new work or how to recover, delay release.
![How to choose the right idempotency key for an event: Keep the same idempotency key for retries of one action; use a new key for a new action.; Write: one [effect] for each [identity], e.g. one standard invoice per approved order.; Check stability, uniqueness, scope and lifetime; include tenant ID for tenant-scoped IDs. Choosing an idempotency key for an event](/covers/choosing-an-idempotency-key-for-an-event-640.webp?v=39704930)