A workflow needs a durable answer to a simple question: what happened to this particular run? Accepting a request, waiting for a decision, and finishing the work are different events. If the interface collapses them into one success message, a person cannot tell whether there is anything left to do.
PROCUX's workflow implementation makes these distinctions explicit. This engineering note follows three parts of that implementation: the identity assigned to a run, the state used when approval is required, and the status the interface shows while it tracks that run.
One identity from admission to the queue
The workflow admission path creates an execution record before it enqueues the work. That record carries the workflow ID, execution ID, initiating user, company context, and input for the run. The execution ID is then passed to the queue with the work request.
This detail matters because the interface needs to follow the same execution that the worker receives. A second, unrelated ID would make the original request difficult to reconcile with later progress. The queue code carries the existing execution identity instead of requiring the interface to guess which run belongs to its request.
Input handling is explicit too. The admission path accepts the interface's input envelope and extracts its business input. A malformed value in that envelope is rejected before admission. A retry has its own newly created execution identity, which is forwarded to the queue.
Focused local tests exercise these paths with controlled dependencies: identity forwarding, company and user context, input handling, retry identity, and queue payloads. These are checks of the request and queue boundary; they do not measure how long a production job takes.
Waiting for approval is a separate state
The approval node constructs a pending approval record and returns a signal that the workflow needs a decision. The executor recognizes that signal and moves the run into waiting_approval.
The executor also saves node outputs as the run advances. Its resume implementation loads the waiting execution, restores those outputs, locates the approval node in the workflow, and continues from the following node when it receives an approved decision. A rejected decision takes the failure path. If the workflow or approval node cannot be found, the resume method raises an error instead of claiming that work has resumed.
These are implementation details of the workflow executor. They do not establish that every PROCUX action uses this same approval path, or that every deployment has the same approval configuration. Permission to submit a decision and execution of the remaining work are separate boundaries that require their own verification.
For the person watching a run, the immediate consequence is concrete: waiting for approval remains visible as waiting. It is not converted into a completion event.
Keep status attached to the current run
The active workflow status hook uses authenticated HTTP polling. It requests the execution being viewed and checks that the returned execution ID matches. It schedules the next poll after the current request settles, so a slow response does not create overlapping polls from that hook.
Changing the selected execution aborts the previous request. The hook also checks the signed-in session before applying a response. If that session changes while a request is in flight, the old response is discarded. A subsequent authorized request can use the refreshed session.
These lifecycle details keep delayed responses from being displayed under a different run or session. The local hook tests exercise slow polling, execution changes, session rotation, and logout while a request is pending.
Report the outcome the system actually has
The interface translates queue admission into a pending state and a successful terminal execution into completion. Failure, error, and timeout outcomes remain failures. waiting_approval stays distinct, and the completion callback runs only for a successful execution.
A temporary failure to fetch status produces a recoverable message and another attempt. A later successful fetch clears that message. An unavailable execution stops polling for that account. Losing visibility into a run is therefore represented separately from receiving a successful result.
This is the engineering principle behind the flow: each visible status should correspond to evidence about the execution being tracked. A request accepted into a queue establishes admission. An approval pause establishes that a decision is still needed. Completion requires a successful terminal result.
What was verified for this note
This walkthrough is based on the current reviewed source and focused local tests for execution admission, queue identity, and interface status tracking. The approval executor's pause and resume behavior was inspected in source; a complete approval-to-external-action production run was not performed for this article.
The tests use controlled dependencies. They establish behavior within those test boundaries, not production throughput, uptime, customer adoption, or business outcomes. The useful result is a concrete account of how the implemented workflow represents identity, waiting, and completion, with the verification boundary left visible.