Workflow Concepts

The Workflow Engine runs platform workflows in Witboost. The platform provides the available workflow types; administrators create configurations that decide where and how those types run.

Core model

Concept	Owner	Meaning
Workflow type	Platform	A registered workflow capability, including its subject type, start events, allowed building blocks, and default definition.
Subject type	Platform	The kind of resource tracked by a workflow, how it is identified, and which context is available for routing and execution.
Configuration	Administrator	Routing settings for one workflow type: name, enabled state, priority, and activation scope.
Configuration version	Administrator	An immutable published snapshot of the workflow definition.
Workflow instance	Runtime	One execution for a resolved subject, pinned to the selected configuration version.

Administrators can configure registered workflow types, but cannot create new types from the UI. Adding a workflow type requires a platform implementation.

Subject types

Every workflow instance has a subject. The subject contract determines:

• the stable identity used to correlate events;
• the context paths available to activation scopes and definitions;
• whether multiple active instances are allowed for the same subject;
• how later events find an existing instance.

For example, Deploy Approval uses a release subject that includes the release identity and environment. System Lifecycle uses a system subject identified by its canonical System URN.

The subject is different from the configuration. Several configurations can target the same subject type, but routing selects at most one configuration for a new start. The selected version remains pinned to that instance.

Configuration selection

When a start event arrives, the engine:

1. resolves the workflow subject and its context;
2. loads enabled configurations with a published version;
3. evaluates each configuration's activation scope;
4. selects the matching configuration with the lowest priority number;
5. creates an instance pinned to that configuration version.

If no configuration matches, no instance starts. Changes to priority, activation scope, enabled state, or published versions affect only future starts.

Configuration and version lifecycle

A configuration owns mutable routing settings and a history of definition versions. Versions have these states:

State	Meaning
DRAFT	Editable and never used for new instances. A configuration can have at most one draft.
PUBLISHED	Current definition available to new matching instances.
RETIRED	Replaced definition retained for instances and history.
ARCHIVED	Read-only historical version.

Publishing a draft retires the previous published version. Existing instances continue with the version they started with.

Instance lifecycle

Instances are shown as:

• Pending while active and progressing;
• Blocked when a required precondition or action cannot complete;
• Completed after reaching a terminal business outcome;
• Cancelled after administrative termination.

The instance history records stages, transitions, trigger data, actions, actors, and timestamps. A blocked instance retains its latest valid state.

Permissions

Workflow administration uses these permissions:

• workflow-engine.definition.view to view configurations and versions;
• workflow-engine.definition.manage to create, edit, enable, publish, archive, or purge configurations and versions;
• workflow-engine.instance.view to inspect workflow instances.

See Workflow Engine permissions.

To perform administrative operations, see Configure and Operate Workflows. For supported fields and building blocks, see the Workflow Configuration and Definition Reference.