A replay feature feels valuable when the product slows down the dangerous part.
Recovery
Replay external events into Shopify Flow safely.
Replay is valuable because it gives a second chance. It is risky because Shopify Flow may repeat real business actions.
The operator needs to compare what happened then with what would happen now.
The team should be able to explain what was retried, why, and by whom.
What changes
A retry button can feel reckless without context.
The operator needs to know whether the original event was accepted, what settings were active, whether the workflow is ready now, and what downstream effects could repeat.
FlowRelay role
FlowRelay makes replay a reviewed operation.
Replay starts from retained event context and receipt facts, shows what to check first, and keeps audit history so recovery does not become invisible improvisation.
Evidence to check
Replay preview checklist
The useful evidence is a cautious preview, not a promise that every event is safe to retry.
Original facts
Sender, endpoint settings, trigger family, mapping, and original handoff result are visible.
Replay should begin from the event that actually happened.
Current state
Current endpoint settings and Shopify Flow readiness are checked.
A replay runs against the world as it exists now, not only as it existed then.
Side effects
Duplicate actions are considered before execution.
The cost of replay is usually downstream, not at the intake layer.
How to start
Replay only when the context supports it.
The review is part of the product value, because it changes replay from a gamble into a governed action.
-
01
Find the retained event
Start from event history, a receipt ID, or a redacted support diagnostic.
-
02
Review the original receipt
Check sender, endpoint, trigger family, mapping, and original handoff result.
-
03
Compare current state
Confirm endpoint settings and Shopify Flow readiness before retrying.
-
04
Run deliberately
Proceed only after side-effect review, then keep the replay audit attached.
Current-path check
Verify the current path before changing it.
Before changing a sender, list the outside system, current receiver, intended Shopify Flow trigger, owner, rollback path, evidence source, confidence level, and any access gaps. FlowRelay, Shopify Sidekick, and authorized agents cannot automatically discover every existing webhook app, Zapier or Make scenario, middleware route, serverless function, or receiver unless those systems are available to inspect. If the current environment is incomplete, start with one low-risk event and document what is unknown.
Side effects
Replay can repeat business actions.
Shopify Flow may send emails, call apps, create tasks, tag customers, start fulfillment work, or trigger partner systems. Treat replay as recovery, not as a casual resend.
- Check whether the workflow is idempotent before replaying production events.
- Use test events when proving setup, not real events with irreversible outcomes.
- Escalate to Shopify Flow or downstream systems when Delivered already happened and the failure was later.
Questions
Common questions.
Is replay always safe?
No. Replay can repeat downstream Shopify Flow actions. Review side effects before using replay on real events.
What should be checked before replay?
Check the original receipt, current endpoint settings, Shopify Flow readiness, and whether downstream actions could duplicate.
When should I not replay?
Do not replay when the event already reached Shopify Flow and the remaining issue is a downstream action that should be handled in Shopify Flow or another system.