Trigger
Normalize the incoming event and verify that its business action has not already completed.
- Receives
- Application event or scheduled work
- Produces
- Accepted workflow instance
A workflow is only as good
as its next decision.
Explore the rules, data and exceptions behind marketing automation. Follow an event through validation, permission checks, delivery and recovery.
Change the conditions.
Follow the decision.
This example activates an email nurture journey. Try a duplicate event, missing identity, withdrawn permission or an unavailable destination.
Scenario conditions
Inspect the example payload
Execution trace
Ready to run- 1Waiting
Receive the event
Preserve the source record, timestamp and processing reference.
- 2Waiting
Validate and deduplicate
Check the required identifier and a scoped processing key.
- 3Waiting
Evaluate marketing permission
Check permission for this channel and purpose before activation.
- 4Waiting
Deliver the permitted action
Separate a business decision from a destination delivery attempt.
- 5Waiting
Record the outcome
Keep the final state, rule version and recovery reference together.
Every path needs an outcome.
Run the scenario to inspect the permission decision, delivery result and recovery path.
Reliable activation depends on current permission, a stable action key and a recorded delivery outcome. Inspect how each condition changes the next step.
Read the implementation guidanceAn executable process with recovery paths
Model the expected action and the conditions under which it must wait, stop or ask a person to decide.
Decide
Evaluate required data and policy conditions before branching to the permitted action.
- Receives
- Validated context and rule version
- Produces
- Action, wait or review decision
Execute
Call the destination through a scoped connection and record its response before advancing state.
- Receives
- Approved action and connection
- Produces
- Destination result and state transition
Recover
Classify the failure, retry only transient conditions and route unresolved work to an owner.
- Receives
- Failed execution and prior results
- Produces
- Corrected or safely replayed work
Step 1 of 4
Inspect the data contract.
Select a field to examine its owner, permitted changes and conflict handling. Clear ownership keeps updates consistent across systems.
| Field or object | Accountable owner | Mapping and control |
|---|---|---|
| Workflow service | Stable across repeated delivery of one business event. | |
| Process owner | Preserved with the decision. | |
| Automation platform | Links the failure to the version and inputs used. |
Resolve the important decisions.
Business failure or technical failure
A missing account owner needs a correction process. A temporary network failure may justify a bounded retry.
Retry version
n8n supports retrying with the original or currently saved workflow. Choose deliberately after a correction.
Validate before handover.
Select the scenarios to discuss with your implementation team.
0 of 3 selected
Test an example workflowPlatform documentation
Which workflow should work better?
Talk through the handoffs, exceptions and manual steps in your operation.