An automation can reach a point where it must not proceed without a decision, some data, or a check. For example, it may need approval before confirming a sensitive operation or have to wait for information that only a person can provide. In these cases, the system must preserve a recoverable state and explain what is missing, rather than simply stopping the current execution.
Designing how to pause and resume an automation in PHP means separating the process state from the execution of the work. The pause must be intentional, persistent, and auditable; resuming must verify that the process is still valid and that already-applied effects are not repeated. This is different from designing a review queue: the focus here is the workflow's lifecycle and its safe continuation.
Distinguish a pause from a wait or a failure
Not every process that stops progressing is paused. An API call that has not yet received a response is an external wait. A network error may warrant a retry. An unrecoverable exception may end the process as failed. A deliberate pause, by contrast, means the workflow has reached a known boundary and requires an explicit condition to continue or end.
Using a separate state for each situation prevents incorrect operational decisions. Retrying an action that is waiting for approval can repeat an unnecessary request; treating a legitimate pause as a failure can trigger alerts or recovery policies that do not apply. Define separate states at a minimum for execution, external wait, intervention required, completed, canceled, and failed. Add an expiration if the business requires a pause to become invalid after a certain period.
Before adding a pause, specify what triggers it and who can resolve it. A pending task that completes automatically when a response arrives does not always need human intervention. A decision with financial, legal, access, or security implications may require it. This distinction determines who can act, what evidence to retain, and what happens if nobody responds.
Persist the state and continuation point
The process must survive the end of a PHP request, a worker restart, and a new version of the service. Store a stable identifier, the current state, the step reached, the reason for the pause, references to the required data, and relevant timestamps in persistent storage. Where appropriate, also record who paused or resolved the process and what decision was made.
Avoid saving only a message such as “waiting for approval.” It does not identify which execution is stopped, which step should continue, or whether the data has changed. Instead, represent the pause as part of the process model, with enough context to validate resumption. Whenever possible, retain references to sensitive information rather than unnecessarily duplicating data; apply access and retention controls appropriate to its nature.
Define the allowed transitions and validate them on the server. For example, a process in the intervention-required state may transition to execution, canceled, or expired; a completed process should not return to execution through an ordinary request. A PHP function can validate the transition, but the rule must also be protected against concurrency in the database, not just in the interface.
Separate process recording from execution
Recording that a process should continue and executing its steps are related, but not identical, operations. If the state is updated and the process ends before the work starts, the workflow may become stuck. If the work starts before the transition is saved, a retry may execute the same step. Design the coordination so that persistent state makes pending work recoverable.
A common option is to save the transition and a continuation instruction in the same database transaction, for example by using a transactional outbox pattern. A separate worker reads that instruction and executes the next step. The specific choice depends on the architecture; what matters is that the system can detect and recover unconsumed work instead of relying on a web request remaining active.
External effects require additional care. A local transaction cannot by itself undo an email that was sent, a charge that was confirmed, or a call that another service has already accepted. Design each step with an idempotency key when the destination allows it, record the result before proceeding, and account for reconciliation or compensation when an operation cannot be safely repeated. Do not mark a step as completed before you know its outcome.
Control resumption, cancellation, and expiration
The resume action must verify the current state, the identity and permissions of the person requesting the operation, and whether the necessary conditions have been met. Showing a button to an authorized person is not enough: the server must validate everything again when it receives the request. If the decision requires a justification or additional data, validate and retain that information as part of the resolution.
Also treat cancellation and expiration as explicit transitions, not as deletion of the record. Cancellation must prevent new steps and make clear whether there are previous effects that cannot be reversed. Expiration must define what happens next: end the process, request another intervention, or route the case to another action. The behavior depends on the business rule and must be visible to operations.
Repeated requests and race conditions are normal: a person may double-click, or two actors may act almost simultaneously. Use a conditional update, a lock, or version control so that only one valid transition succeeds. A second request should receive a result consistent with the current state, without rerunning effects. Store an operation identifier or idempotency key to recognize retries.
Make the pause understandable and verifiable
The operational view should explain why the process is stopped, which step is pending, what information is missing, who can act, and the consequences of each option. Avoid ambiguous buttons or actions that combine approving, correcting data, and continuing. Show only the information needed to make a decision, with access restricted according to role. A transition history helps distinguish a legitimate wait from a blocked or misconfigured process.
Test the workflow with interruptions before and after each external effect. Verify that a restart does not lose the pause, that repeated resumption does not duplicate actions, and that cancellation prevents subsequent steps. Include cases involving data modified during the pause, revoked permissions, expiration, late responses, and two simultaneous requests. Also check logs and alerts: they should make it possible to locate the process and understand the next step without exposing secrets.
Checklist for deciding what should happen
- Wait: An external response is in progress, and the system can continue automatically when it arrives, with time limits and recovery defined.
- Pause for intervention: An explicit human decision or input is needed before subsequent steps can run.
- Retry: A transient failure has occurred, and repeating the step is safe or protected by idempotency.
- End: There is no valid continuation, or the process has completed, been canceled, expired, or definitively failed.
Before deploying the workflow, confirm that every transition is authorized, the state persists, previous effects are not repeated, and the team knows how to resolve the pause. If you cannot say what will resume, with which data, and under what conditions, the process does not yet have a safe continuation point.
