Workflow recovery: who owns state between a CRM, a reviewer and a worker?

Connector counts tell you little about a workflow that survives a restart. The harder question is what happens when an external action may have succeeded but its acknowledgement disappears. A platform can remember the execution path without knowing the authoritative business outcome.

Four October publications illuminate that distinction. Read together, they suggest a useful purchasing and architecture test: identify who owns delivery, execution history and confirmation of the external result before choosing where the workflow runs.

Four publications, different responsibilities

Microsoft’s October 12 Durable Task discussion explicitly separates durable coordination from external effects the application must reconcile. Temporal 1.32.1, released October 8, includes task-routing and task-queue data fixes. A dedicated execution system has its own maintenance lifecycle.

n8n’s October 12 DevOps comparison distinguishes deployment, infrastructure and cross-tool coordination. Workato’s October 13 conference report describes customers building reusable integration layers. It is a vendor-hosted account, not independent evidence of product superiority.

The connection between them is architectural. Transport delivers work, an execution system tracks progress, and a business record establishes what was accepted. Guarantees at one boundary should not be silently extended to another.

One request has several states

A customer onboarding request has a business state: whether it is approved and who may amend it. Its execution has a technical state: which activity started, what results were recorded and when a wait should resume. An external provider has another record: whether an account actually exists.

Those states can diverge. The provider creates an account, but the worker loses the response. Repeating the action under a new identity may create a duplicate. Marking the entire request failed can be equally misleading when the account already exists.

A stable operation identity helps resolve that ambiguity. A retry uses the same identity and immutable content. If the result is unknown, the integration first checks what happened to that operation. This is a design requirement, not a blanket claim that any provider supports safe retries; the actual API contract decides the available recovery path.

Approvals need the same care. A message saying “approved” may arrive late or twice. The durable business decision, including its applicable version, should authorize continuation. Receiving a notification is merely evidence that something may have changed.

A hypothetical partner onboarding flow

Suppose a manager opens a CRM request, a supervisor approves it, an external system creates the partner account, and an employee receives a verification task. This is a worked design scenario, not a customer result or an integration compatibility claim.

Assign the request a permanent key. Store the supervisor’s decision against the version of the partner details being approved. When a worker resumes, compare versions: approval of old banking or contact details must not authorize submission of amended details. The external creation request then uses the same operation identity throughout its lifetime.

Now interrupt the connection immediately after submission. The next safe action depends on the provider: query by operation key, inspect a previously saved external identifier, or route the unresolved outcome to an operator. Resending blindly is acceptable only when the API and the business rules make it safe.

Give the employee’s follow-up task a stable identity as well. Otherwise recovery can create duplicate work and two employees may process the same partner. Completion means the mandatory records agree. A successful worker run alone is insufficient.

There is a product decision hidden here. The interface needs to distinguish “waiting for approval,” “provider outcome unknown” and “needs operator review.” Combining those into a single red error encourages staff to restart work that may already have happened. Better status wording is part of recovery design, not cosmetic polish.

When a dedicated engine earns its cost

A short process already handled reliably with a database, a queue and a few handlers may not benefit from another runtime. Long waits, independent branches and human decisions increase the cost of maintaining a custom continuation protocol. That is where dedicated coordination deserves evaluation.

Include the cost of updating the executor, retaining history and keeping old executions compatible with new code. Specify who handles ambiguous outcomes. Acceptance should cover a restart during a wait, a lost acknowledgement and a repeated event, with the final CRM and provider records checked explicitly.

The mechanism is developed further in background workers and retries. The AmoCRM project offers related workflow and communications context. For requests crossing several systems, workflow automation planning should start with recovery rules and an owner for the final result.