Workflow Service
The Workflow Service utilizes a configuration-driven architecture and a four-layer abstraction model to separate business logic from user interface rendering for data governance.
Executive summary
The Workflow Service acts as the governance engine for business data. It enables you to perform the following actions:
- Group related changes across different domains using projects and workspaces.
- Collaborate on drafts without affecting live data.
- Enforce governance gates and approvals before data is published.
- Track governance actions and entity modifications for auditing.
Core concepts and hierarchy
Projects
A project is a finite initiative to track work for specific channel deployments. Projects are tied to a single deployment region (for example, "US East"). A project ends when the system publishes its contents.
Workspaces
A workspace is an isolated environment within a project for modifying data. Workspaces identify the specific entities under modification. Workspaces do not link to each other. If conflicts exist between two workspaces modifying the same item, the most recently published data is preserved.
The four-layer architecture
The system is organized into four layers of abstraction to move from system definition to runtime execution.
Layer 1: Global definition
This layer defines the capabilities possible in the system and is stored in the
task_library table. It holds definitions for individual
capabilities (for example, UI Field Control). It defines how items
are configured rather than when they occur.
Layer 2: Administrator configuration
This layer defines the standard process for a business goal and is stored in the
workflow_template table. Administrators chain together steps
(for example, Draft, Review, and Published) and configure specific tasks for each
step.
The resolution pattern and stateless UI
The system uses a resolution pattern to ensure security. The frontend is stateless regarding permissions; it renders based on the specifications of the backend logic engine.
For example, if a template defines a rule as edit_scope:
AUTHOR_ONLY, the engine evaluates this against the request context. If the
current user is not the author, the engine resolves the permission to
READ_ONLY. The Workflow Service sends this final result to the
gateway. The UI never receives the raw configuration rule, only the final computed
state.