A failed step.
A careful retry.
The contact was saved, but the team notification failed. Restarting everything could create a duplicate. This example keeps the completed work and retries only what’s unfinished.
Independent offline demonstration
Built with synthetic data, not a client repair.
The everyday problem.
An automation stops halfway through. Clicking “run again” seems simple, but some of its steps have already happened.
What a repair needs to check.
Find the failed step, confirm what already succeeded and decide what can safely run again. If the result is uncertain, investigate before retrying.
Try the recovery.
A small working simulation in your browser. No real contacts are created and no messages are sent.
Where the workflow stopped
- Save the contactDone
- Notify the teamFailed
- CRM contacts
- 1
- Confirmed notifications
- 0
Keep the saved contact.
The notification definitely failed. Retry that step without saving the contact again.
The useful part.
A retry should not repeat work that already succeeded. And a timeout does not always mean nothing happened. Those two checks can change how a broken workflow should be repaired.
For an existing automation.
I’d start with the actual failed run and the tools involved, then agree the fix, test the relevant failure cases and document how to recover.
Explore repairs & improvementsSee the build details
A deliberately small model.
The local state model preserves one saved contact, permits one confirmed notification after a known failure, ignores repeat attempts after completion and blocks an uncertain result. Reset starts a fresh demonstration.
What it does not prove.
This is not an integration with a real CRM or email provider. It does not implement a durable ledger, concurrent workers, provider receipts or live retries. Those controls depend on the actual system and must be tested in a real repair.