When do we actually need it?

When a process crosses several systems, when a partial failure would leave things inconsistent, or when anything in the sequence must not happen twice. Below that, a straightforward chain of triggers is simpler and adequate. The threshold is usually reached before anybody notices it has been.

Do the ordinary automation platforms provide it?

To varying degrees, and this is worth comparing directly rather than assuming. Ask what happens when step three fails: whether the run can resume, what is retried, what you are told, and whether the history is inspectable afterwards. Those answers differ far more between products than the connector counts do.

What should we build first?

Protection against running twice on any step that sends, pays or deletes. It is a small amount of work in advance and effectively impossible to retrofit calmly once a duplicate has reached a customer. Everything else in this subject can be improved later.

Glossary

Workflow orchestration

Workflow orchestration is the machinery coordinating many automated steps across different systems: what runs in what order, what happens when one fails, what is retried, and what picks the work up afterwards.

In plain terms

Somebody has to be in charge of the sequence. When five steps run across four systems and the third one fails at two in the morning, something must decide whether to wait, retry, skip, alert somebody or abandon the whole thing tidily. That deciding is the job, and it is unglamorous work that nobody notices until it is missing.

Why it matters

It is the difference between an automation that demonstrates well and one you can leave running. Everything works when every step succeeds, and the hard part has always been the other case: partial failures, systems that were briefly unavailable, work half done. Where your process handles money, customers or anything that must not happen twice, this is the part deciding whether a bad night becomes an incident or a line in a log you read on Monday.

How it works

It knows where each piece of work has got to, which is what makes recovery possible at all. Without that record a failure at step four means starting again from step one, and starting again is exactly what you must not do when step two already sent your customer an email or moved their money.

Retrying is handled deliberately rather than hopefully. Some failures are worth retrying after a pause, some are worth retrying with a longer pause, and some will never succeed however many attempts follow. Distinguishing them is most of the craft, because retrying the third kind forever is a common and expensive way of achieving nothing.

Running twice has to be impossible for the steps where it matters. The standard approach is recording an identifier for each piece of work as it is handled and refusing anything already seen. That is cheap to build in advance and very hard to add after a duplicate payment has raised the question.

It gives you a record of what actually happened, step by step, which is the part people value later rather than at the time. When somebody asks you why a customer received two messages last Thursday, the answer either exists or it does not, and that was decided months earlier by whether anybody chose this over a chain of triggers.

Five steps, and the one that failed

Nothing here is exotic and every part of it is uncomfortable. Two steps completed, one of them irreversible, and the sequence stopped in a place nobody designed for. A system that only knows the run failed has one option, which is to start again, and starting again charges somebody twice. A system that recorded where the work reached can resume from the third step, or hold the whole thing for a person, or abandon it in a state somebody can act on. That difference is the entire subject. It is also why the first thing worth building is not the happy path but the record of what has already been done, since every sensible response to this situation depends on having it.

Seen in the wild

Build a multi-step flow and then deliberately break the third step, which shows you what the platform does with the two steps that already ran.
n8n
Look at the run history of a scenario after a busy week and count how many attempts failed, retried and eventually succeeded without anybody noticing.
Make
Chain several actions on one trigger and check what the platform tells you when the last one fails, which is where the differences between products live.
Zapier

Common misconceptions

People assume

It is just automation with more steps.

In fact

More steps is what creates the need for it. One step either works or does not; five steps across four systems can fail in the middle and leave things half done, and deciding what to do about that is a different problem from doing the work. The distinction shows up only on the bad days.

People assume

Retries make things reliable.

In fact

Retrying the right failures does. Retrying the wrong ones repeats a request that already succeeded, or hammers a system that is refusing you for a reason, or spends an afternoon on something that will never work. Reliability comes from telling those cases apart, not from the number of attempts.

Telling them apart