· Rakesh Gangwar
Suppose a process requests a missing document and then nothing happens for four days.
There is no useful computation to perform during those four days. But the process is not finished. It still needs to know which document it requested, which case it belongs to, what has already been checked, when to escalate, and what to do when the document arrives.
That quiet period is where a short-running automation and an operation part ways.
Waiting is a state, not an empty space
An ordinary script is designed to start, do some work, and end. A business process may start now and finish after a counterparty responds, a reviewer approves, or a date is reached.
Keeping a script alive is not the answer. Neither is asking a person to remember the case. The process needs a durable state that says: the completed steps are recorded, the next transition depends on a particular event, and this is the deadline if that event never arrives.
While it waits, it should not consume a worker just to preserve its place.
The incoming event has to find the right run
When the requested document arrives, receiving it is only half the problem. The system has to correlate it with the case that is waiting for it.
That correlation may use a case identifier, a reference in a webhook, or a message from an integration. Once matched, the event changes the run from waiting to ready. The process can validate the new evidence and continue from the next step.
Without that state, teams fall back to polling and inbox searches. A scheduled job repeatedly asks whether anything changed. An analyst notices a reply and reopens the case. Both approaches can work, but both make recovery and duplicate handling harder than they need to be.
Timeouts are part of the business process
Not every wait ends with the expected response. The deadline may pass. The document may be malformed. The same webhook may arrive twice. A service may be unavailable when the process resumes.
These should be designed as branches rather than discovered as incidents. A timeout may send a reminder, route the case to a person, or close a request. A failed system call may retry under a declared policy. A duplicate event should not repeat an irreversible action.
The important point is that the run retains its place through all of them. If a service restarts while a case is waiting for approval, the approval does not disappear and the process does not return to step one.
Durable execution changes what can be automated
Superprocess uses Temporal-backed execution so a process can wait on a human or external signal and resume with its prior state. Its connectors call APIs and query databases; configured inbound events are correlated with the run they should resume.
This still needs to be designed: which event resumes which case, what the deadline means, and how retries avoid repeating an external action. Durability preserves the run; it does not choose that policy.
That infrastructure is deliberately unremarkable to the operations team. They should see a case waiting for a named reason, its deadline, and the action that will follow. They should not have to know which worker was running when the case paused.
Most of the elapsed time in an operation may contain no activity at all. A process is durable when it can own that time instead of asking a person to own it.