How requests move through their route¶

A workflow route determines which work opens next and when the request can finish. Completing your own task may leave other tasks, approvals or receiving work outstanding. A single current-step label cannot describe every branch of a request.

Availability: the backend implements assigned tasks, approvals, route selection, selected parallel-work patterns and subworkflow tracking. Connected frontend execution and complex route recovery remain under verification. Saved configuration and a successful simulation do not establish that every automated behavior suggested by a route is implemented.

For screen instructions, use the requester and reviewer guide, personal work and queues and approval decisions. This page explains what those actions mean in the running workflow.

Starting and advancing work¶

A request starts from a published workflow definition. The runtime opens its configured start steps in order. Work, queue, document-upload and form-completion steps create assigned tasks. Approval steps create the decisions and tasks required by their approval rule. The assignment and timing services participate when tasks open; unresolved people, queues or routing dependencies can prevent progress.

A decision step chooses its next route without creating a human task. Split steps open parallel work; joins determine when that work may continue. Reaching the end either completes the local workflow or starts its configured completion handoff.

Current routing limit: stored condition expressions are not evaluated by the inspected runtime selector. A condition such as an amount threshold must not be treated as an enforced automatic rule simply because it appears in a saved definition. The selector uses a chosen route name when supplied; otherwise it uses the default route or the first route in configured priority order. The route owner must verify actual behavior before relying on conditional automation.

Likewise, storing action text on a route does not establish that an email, external update or other arbitrary action will run. The current runtime has specific completion, rejection and correction behavior; it is not a general action-script executor. Ask the process owner to clarify any promised automation that has no verified implementation.

How the next owner is chosen¶

A task can be routed to a configured position, a primary, functional or advisory manager, an organization-unit head, or a shared queue. The route's position context matters: “manager” does not automatically mean the person currently using the screen. Position routing normally uses its primary authority, then acting authority when the primary is absent, then a configured fallback position. Other people sharing a position are not automatically chosen by this task-assignment path. An unresolved target or a circular fallback can stop progress; ask the process owner to correct the assignment rather than create another request.

A queue assignment identifies the queue rather than choosing an individual. Queue membership and claiming are separate parts of taking responsibility. A queue name displayed on a template does not prove that someone is currently available to do the work. Parent-reporting-position and named-rule routing remain deferred; a stored choice does not make those routes executable.

Approval assignment takes the authority body's active voting members who have a staff identity and creates the decision list in the returned membership order. The configured approval mode determines how many decisions are needed: all selected people, any one, a specified count, quorum or majority. An empty voting list prevents approval assignment. These are people/decision counts, separate from the parallel-branch counts below. Process owners must keep body membership, achievable approval rules and current responsibility accurate; a successful lookup or a visible person's name is not a completed decision.

Parallel work and when it rejoins¶

A parallel split opens several branches of work. A join is the point where the configured completion rule decides whether the route can continue. The current implementation records completed branches separately from individual approval decisions.

These are branch counts, not counts of approving people. One approval branch may itself require several decisions. Its approval rule must resolve before that branch advances to the join. Read approval decisions for those rules.

When the join becomes satisfied, the runtime cancels the other still-active tasks registered to that branch group and advances beyond the join. This matters for Any branch and Required count: another person's task may become cancelled because enough other work finished. Cancellation here does not establish that already-performed external work was reversed.

If your task has become cancelled, refresh the request and read its current state before attempting further work. A repeated completion of an already completed, cancelled or skipped task does not reopen it through the normal execution path. Ask the process owner if the new state conflicts with the intended business requirement.

Layouts that need further verification¶

The inspected runtime and tests establish simple branches that open human tasks and then reach their join. They do not certify arbitrary nested splits, multi-step branches, repeated visits to a group or concurrent completions.

In particular, the current branch tracking is tied to the initial branch steps. A longer path that reaches the join from a later step can fail to find that tracked group and advance without its completion rule. Do not rely on a successful structural simulation as proof that such a route waits correctly. The process and engineering owners must reconcile these layouts before rollout.

A branch must open a supported human task at the split. A branch beginning with an automatic decision, another split or an end is not established as a supported nested arrangement. A required count also needs to be achievable by the actual distinct branches. Avoid using an unverified layout for work whose approvals or completion must be guaranteed.

What a subworkflow currently means¶

A subworkflow is intended to represent related work described by another workflow definition. In the inspected execution path, the step creates an assigned parent task and a tracking record that names the child definition. It does not start a separate child workflow instance.

Completing that parent task marks the tracking record completed and advances the parent route. This does not prove that the child definition's steps ran or that a child outcome was checked. The design or configuration may name a child workflow, but automatic child execution, result propagation and coordinated cancellation require further implementation and verification.

Managers should make this limit explicit when assigning such work. Do not tell users that another workflow was launched merely because a subworkflow tracking entry appeared. Confirm the actual work performed and its owner through the verified process.

Exceptions and recovery¶

Return, rejection, cancellation and approval are different operations. Returning for correction preserves the request and reopens permitted work; it does not promise to restore every parallel branch. Manual interventions describe reassignment and cancellation limits. Automatic timing and authority interventions have their own ownership and remain separate from a join rule.

Business owners should test the complete route with representative roles and realistic examples before rollout, including each branch, rejection, correction, unavailable assignments and uncertain results. A graph that can reach an end is not sufficient evidence of correct runtime decisions, safe recovery or successful receiving work.