Workflows that survive a restart

What it is, and what it is not

A generic engine over definitions that live as tenant data: triggers, conditions, actions, parallel and sequential branches, timers, escalation, rejection and rework. Definitions are built visually and versioned like the rest of your configuration, promoted from a sandbox with rollback.

It is not a change process with the labels made editable. Change management uses this engine, but so do quality records, document approvals, supplier onboarding and anything else you model. One engine means one set of semantics to learn and one place where escalation behaves consistently.

It is also not an automation platform. Workflows route work to people and take bounded actions on objects inside Manufacturing PLM. They do not call arbitrary external services, because a workflow engine that can do anything becomes a place where business logic hides from review.

The mechanism: durability is the row, not the queue

Everything about where an instance has got to lives in its WorkflowInstance row and its task rows. Advancing reads those rows and works out what should happen next; there is no worker holding a position in a script and no queue entry that constitutes the state.

That is why an instance survives a restart mid-flow, resumes exactly where it was, and can be inspected by looking at the data rather than at a runtime. A two-week approval with three outstanding tasks is three rows, and if the service is redeployed on day four, day five continues.

Parallel branches rejoin properly rather than racing. Two reviews issued at once both complete before the approval task is created, and the join is a condition over task rows rather than a callback that might fire twice.

Timers are dates on rows, evaluated when the engine runs, not setTimeout in a process that will not exist next week. An escalation on day three escalates on day three even if nothing was running on day two.

The failure it prevents

A change sits waiting on a manufacturing review. The reviewer is on leave, the task has no timer, and nobody is looking at a queue they do not own.

Eleven days later somebody asks why the change has not released. The answer is that it is fine, it is just waiting — and it would have waited indefinitely, because nothing in the system had an opinion about how long a review may take.

The version of this that costs money is subtler: the reviewer forwards the request by email, somebody else approves informally, and the change releases with a task still open and an approval recorded against the wrong person. Escalation on a timer, with the task staying open and assigned rather than reassigning silently, prevents both — the work moves and the record stays true.

How it meets the rest of the product

The rules engine is deliberately separate from the AI. Conditions are deterministic expressions over object attributes and relationships — does this change affect a released part, does it touch a plant, is the cost impact above a threshold — evaluated the same way every time. An approval route decided by a model would be a route nobody could reproduce or defend.

Approvals carry electronic signatures with the meaning recorded: approved, rejected, abstained, delegated, escalated. Delegation and out-of-office reassignment are first-class, so covering for a colleague does not mean sharing credentials — which is what actually happens when a system makes delegation hard.

Rejection routes to rework rather than terminating the instance, and the reason travels on the task. A rejected change that has to be re-raised from scratch loses the discussion that produced the rejection, which is usually the most valuable thing in the record.

Agents can be workflow participants at the tier you set — an agent that prepares a draft or attaches an analysis is a task like any other, audited with the agent named as actor. What an agent cannot be is an approver.

How it meets your ERP

Workflows do not reach into your ERP. A workflow completes, a change releases, and publication happens as part of that atomic release — the connector is downstream of the workflow rather than something a workflow step calls.

That separation matters because it keeps retry semantics in one place. If a publication fails, the connector's bounded retry handles it and the failure appears in sync history; the workflow does not need to model the ERP being unavailable, and nobody has to reason about a half-published change caused by a workflow step timing out.

Conditions can read ERP-sourced context that has already been synced — routing a change to a different approver when the affected parts carry more than a threshold of on-hand stock, for instance. That reads a cached value with an as-of stamp rather than making a live call mid-workflow.

Where the boundary is

No arbitrary code execution and no outbound calls to services of your choosing. Actions are a bounded set operating on Manufacturing PLM objects — create, transition, assign, notify, attach. A workflow engine that can call anything becomes the place where business logic hides from code review, and it is unpickable once that has happened for two years.

It also does not schedule work in the world. A workflow can require an approval before an effectivity date, but it cannot make a plant absorb a change, and nothing here replaces the conversation about when a cutover actually happens.