Workflow Design
Part of Designing reliable workflows between business applications
Choosing a workflow trigger from an actual system event
Select a workflow trigger by checking the business transition, event fields, filtering, replay behaviour and destination effect it permits.
Choose the trigger for the business transition that permits the next action. “A record changed” may include an address correction, a status update or an automated write. Name the source event, the state it must represent and the action it permits before configuring the workflow.
Suppose a paid order should open a fulfilment request. “Order created” might occur before payment, while “order modified” might occur repeatedly. The choice depends on what the order system emits and when its payment state is authoritative. These event names are illustrative.
Write the event contract
For each candidate event, record its producer, event name, event or record ID, relevant state, timestamp and available fields. Then ask:
- Does it occur after the business condition is confirmed?
- Can it occur for a change that should do nothing?
- Can another event lead to the same business action?
- What happens if the workflow is unavailable when it occurs?
A rule could read: “When the order system reports a transition to paid, and the order is eligible, request fulfilment once for that order.” This separates the signal, the eligibility check and the destination effect.
If the source exposes only a broader event, check its current state before writing to the destination.
| Candidate signal | Question to settle |
|---|---|
| Record created | Is the record already eligible? |
| Record modified | Which changed field or resulting state matters? |
| User presses a button | Is the action authorised and is the record still eligible? |
| Scheduled scan | Which records qualify, and how will later scans avoid repeating work? |
Event contract fields to record
- Producer
- Event name
- Event or record ID
- Relevant state
- Timestamp
- Available fields
Candidate signal and question to settle
- Record created
- Is the record already eligible?
- Record modified
- Which changed field or resulting state matters?
- User presses a button
- Is the action authorised and is the record still eligible?
- Scheduled scan
- Which records qualify, and how will later scans avoid repeating work?
Check delivery and filtering
A polling trigger periodically checks a connected service, while a webhook trigger receives notifications. Those labels alone do not establish what an integration will recover after an outage. Power Automate, for example, documents different behaviour for polling and webhook triggers when a flow is turned off and back on. Check the selected source and connector’s restart, retention and replay rules.
Use a documented trigger filter where it can exclude irrelevant events before a run begins. Check eligibility again near the destination action if source state may have changed. If an outbound write can trigger the same workflow, identify the loop and define how to break it.
Polling vs webhook triggers
- Polling trigger
- Periodically checks a connected service
- Webhook trigger
- Receives notifications
- Restart, retention and replay
- Check the selected source and connector’s restart, retention and replay rules
Separate event identity from action identity
An event ID can identify redelivery of one event. The business action needs its own stable reference: two different events could both request fulfilment for the same order. Agree with the destination owner on a lookup or safe retry rule for that reference.
Do not assume arrival order matches business order. If cancellation can follow payment, decide whether a late paid event should still create work. The source’s current state or version may need checking when the decision is made.
Check the selected trigger
In a safe environment, prepare an eligible transition, irrelevant edit, repeated event and stale event. Write the expected destination effect for each, then inspect trigger history and destination records. Check the restart path against the selected platform’s documentation.
Test the selected trigger
- Prepare an eligible transition, irrelevant edit, repeated event and stale event
- Write the expected destination effect for each
- Inspect trigger history and destination records
- Check the restart path against the selected platform’s documentation
