Workflow Design
Part of Workflow testing and deployment
Building test cases for every decision branch
Turn workflow decisions into cases with expected routes and destination effects, including compound conditions, defaults and boundaries.
List every workflow decision and create cases that take each intended route. For each case, state the expected route and the destination effect before running it. A branch is covered only when the relevant input reaches it and its result is checked.
Turn the workflow into a route list
Start at the trigger and mark each filter, condition, switch, approval outcome and error route. Record the values each decision reads and where each result goes. Include a default route and a route that should take no external action.
Suppose a hypothetical workflow creates a fulfilment request only for a paid order with a supported delivery method. Its rules could produce this case sheet:
| Case | Payment | Delivery method | Expected route | Expected effect |
|---|---|---|---|---|
| A | Paid | Supported | Create request | One request linked to the order |
| B | Unpaid | Supported | Stop as ineligible | No request |
| C | Paid | Unsupported | Hold for correction | No request |
| D | Unpaid | Unsupported | Stop as ineligible | No request |
| E | Missing | Supported | Look up the source state or hold | No request until eligibility is known |
The rules and outcomes are invented for this example. In a real workflow, use the source and destination contracts to define them. Cases B and C have the same immediate record count but different decisions to record.
Add boundaries and combinations that matter
For a compound condition such as paid AND supported, test the true and false value of each part. Add combinations where evaluation order changes the outcome, or where a missing value could cause an error before the intended hold route. For numeric or date thresholds, use values immediately below, at and above the boundary. Include an unrecognised value for any catch-all route.
Nested decisions can create many combinations. Prioritise those that reach a different action, error route or business outcome. Record any route that cannot safely be exercised. Do not claim complete coverage from one test of a decision that can receive materially different inputs.
Priority Testing Combinations for Compound Conditions
- Paid AND SupportedTrue, True → Create request
- Paid AND SupportedFalse, True → Stop as ineligible
- Paid AND SupportedTrue, False → Hold for correction
- Paid AND SupportedFalse, False → Stop as ineligible
- Missing ValueLook up source state or hold
Check effects as well as routing
A trace showing the chosen branch does not establish that a destination record was created or withheld. Record the initial destination state, expected result and observed result separately. If the destination accepts work for later processing, inspect its later outcome. Use a fresh test identity or a known starting state so an earlier record is not mistaken for the result.
Choose a safe test surface for each case. AWS Step Functions TestState can execute a supported state without creating a state machine or updating an existing one. Its API supports mocked service integrations; enhanced mocking options are available through the AWS CLI and SDKs.
Power Automate cloud-flow testing offers manual triggering and, after a manual test, an automatic option that can reuse a recent trigger or repeat a test run. These facilities exercise paths; checking the destination remains a separate task.
Keep the case sheet as a plan until observed results are entered. Record the workflow version, input reference, expected route and effect, actual route and effect, and any discrepancy.
