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.