What happens when an automated workflow fails?
Find the last action that you can confirm, then decide whether to retry a step, run the whole workflow again or leave it for review. Start with one reversible job, such as copying a waitlist signup into a review list.
What should you automate first?
Start with a job that already has a clear result. If you copy a waitlist signup into a review list every day, you can write down what starts that job, what information to carry over and where the finished row belongs.
| Job | What to ask the tool for |
|---|---|
| Copy a signup with known fields | Use a rule that receives the signup and writes those fields to a list. Keep the input and result predictable. |
| Suggest a label for a note someone typed | Use an AI step for the suggestion. Keep the note and suggested label together so someone can review them. |
| Summarize a set of signups for a meeting | Give an agent a bounded task and review its output. Use a file or a pasted sample before giving it access to an app. |
| Reserve an appointment or grant paid access | Let your app own the saved decision. A separate workflow can follow up after the app has recorded it. |
Does the connector support the action you need?
Check the starting event, the exact write and the account it will use. A connector is the part that gives one tool access to another app. Its name tells you which app it connects to. The action tells you what it can do there.
For a signup list, you need the source event and the fields it carries, such as a signup ID and an interest. At the destination, find out whether the action always adds a new row or can save one row under that ID. Check whether the action and account you need are available on your plan and in your region.
Use a separate test account with access only to the practice source and destination where the service permits it. Confirm which workspace and list it can change. If the available connection can reach records you cannot risk changing, keep the exercise on paper.
Compare tools
Scroll the table sideways to read every column.
| Tool | Which actions does it run?What starts the work and what account or data it needs. | How do you recover a failed run?Where you inspect it and how much can run again. | What can stop a duplicate?Where a repeated event or write can be stopped. | What are you charged for?The billing unit or the work you have to operate. | What can you move?The workflow or output you can keep and what needs reconnecting. |
|---|---|---|---|---|---|
| Zapier | Start with an event in a connected app, then select each action and the account it runs under. | Use Zap History to find an errored action. A full replay can run earlier successful steps again. | Polling can screen repeated IDs within a Zap. A destination action can still create a duplicate. | Most successful actions use tasks. Check built-in exceptions and what happens at your plan limit. | Team and Enterprise can export workflow JSON. Check or reconnect app accounts after import. |
| Make | Connect modules and map fields. Use filters when different inputs need different paths. | Retry a saved incomplete execution from the failed module. Scenario replay uses the old trigger input. | A Data store can reject a repeated key when overwrite is off. Check writes in other destinations separately. | Standard non-AI operations generally use one credit. AI usage can have other rates or provider charges. | Export the scenario blueprint. Create account connections again and keep the data separately. |
| n8n | Use nodes to define each step. A manual test can shape fake data without an app account. | Retry with the original or saved workflow. Finished steps keep their results. The failed step can process its entire saved input again, even items it already handled. | Filter repeated input in a node and use a unique key where the final record is saved. | Cloud meters whole workflow executions. Self-hosting leaves the server and its operation to you. | Export workflow JSON. Recreate credentials and verify data and dependencies before switching. |
| Flowise | Historical upstream. Existing visual flows can include a model, named tools and a human decision. | Archived docs describe saved checkpoints. Check the actual deployment and its outputs before resuming. | A flow checkpoint records progress inside the flow. Check external actions against their own results. | The upstream project reached end of life. Current hosted access and plan terms remain unverified. | Historical Cloud migration exported selected JSON without credentials. Confirm access to the copy you have. |
| Manus | Give an agent a goal and inputs. Connectors can let it interact with external apps. | Read the task output and check any connected destination before asking it to try again. | Match proposed results to the supplied IDs and review them before applying changes. | Credits vary with task processing. Deployed WebDev applications have separate usage charges. | Keep supported output files and original inputs. Verify any project export needed for a move. |
How can you test one signup and a repeated delivery?
Use paper with two made-up signup IDs and an empty review list. This lets you decide what should happen before you connect a real form, inbox, payment or customer account.
- Save the first signupWrite demo-103 next to a made-up name and interest. Copy the signup to the review list under that ID. Look up the ID to confirm the row exists.
- Deliver the same signup againSend a second copy with demo-103. Keep the one existing row. Deliver a separate signup under demo-104 and check that it gets its own row. In an app, choose a destination that can enforce one record per ID when it writes.
- Pretend the confirmation was lostAssume demo-103 saved but the workflow never heard back. Look up the ID before retrying. If the row exists, continue from that result. If you still cannot tell, keep it pending until you can check.
- Review one proposed changeSuggest a label for demo-103 and keep its original note beside the suggestion. Approve or decline the exact label. Leave the row as it was on decline or no answer. Make no outgoing action in this practice.
What should you check before retrying a failed workflow?
Find the last step with a confirmed result. Compare the run history with what the destination actually saved. A step can finish writing and still lose its reply.
| What you can confirm | What to do next |
|---|---|
| The signup row exists and the review item is still missing | Keep the signup row and finish the remaining step. Give the review item its own saved status if it can be retried. |
| You cannot tell whether the row was saved | Keep the result pending and look it up by its ID. Use the same ID if you later need to retry the save. |
| The tool offers to replay the whole run | Check what a full replay would repeat. A step that already succeeded may send, charge or create again unless the destination protects it. |
When should a person approve an action?
Ask for approval when a proposed change affects another person or a record they rely on. Show what will change, who or what it affects, and the exact content to approve.
Review a draft message with its recipient before sending. Make a decline or expired request stop that action. If a recipient or message changes after approval, show the revised version for a new decision.
Keep permissions limited as well. A note in an instruction can guide an agent. The connected account determines which actions are available to it.
What will the workflow cost to run?
Work out what the service counts before multiplying by your expected volume. A task can mean one successful action. An execution can mean a run of the whole workflow.
Take one typical signup and count the actions, whole runs and any AI work in the configuration you plan to use. Repeat the count for a failed attempt and a replay. Billing varies by plan and by what actually runs.
If you run the workflow service on your own server, plan for updates, access, backups and recovery. A connected app or model service may still charge for its work.
What should you save before moving a workflow?
Keep a copy of the workflow, a list of the accounts it needs and the records it has already changed. Store those pieces separately so you can rebuild and check the result.
A workflow export can carry the steps without the records or credentials. A credential is what allows the new copy to use an account. Reconnect only the intended account, and check exported files for sample values or saved secrets before sharing them.
Rehearse the move with a fake signup and an earlier ID. Confirm the new copy can handle both. Decide which copy will receive new events before you switch so the old one does not keep processing them.