Workflow Engine Overview
The Workflow Engine is OneStream's orchestration layer. It does not store data (that is the Finance Engine's job) or parse files (the Stage Engine handles that). Instead it governs who can input data, when data is locked, and what steps users must complete before results are certified. Every financial process — closing the books, loading actuals, entering budgets — runs through a Workflow. If you think of the Finance Engine as the database and the Stage Engine as the pipeline, the Workflow Engine is the traffic controller that decides when each pipeline runs, who is allowed to trigger it, and what happens after data lands.
Five Responsibilities
The Workflow Engine owns five distinct areas of control:
| Responsibility | What It Controls |
|---|---|
| Task Sequencing | Defines the steps users see on the task bar — Import, Validate, Load, Process, Confirm, Certify — and the order in which they must be completed. |
| Entity Assignment | Maps entities to Workflow Profiles so each legal entity has the right data entry path, task list, and security configuration. |
| Status Tracking | Tracks whether each Entity / Scenario / Time combination has been imported, processed, certified, or is still pending. |
| Locking | Prevents changes to certified or locked data. Once a workflow unit is locked, users cannot modify values unless an administrator explicitly unlocks it. |
| Security | Controls who can execute each step — who can load data, who can certify results, who can unlock a previously locked period. |
Where Workflow Fits Among the Seven Engines
OneStream's architecture is built on seven interconnected engines. The Workflow Engine sits at the centre, governing the Stage Engine and the Finance Engine rather than processing data itself.
Data Quality feeds into the Workflow Engine because validation results influence whether a workflow step can advance. BI Blend and Presentation sit downstream — they consume data the Finance Engine produces after the Workflow has approved it.
Core Concepts
| Concept | Description |
|---|---|
| Workflow Profile | A configuration object that binds an Entity (or set of Entities) to a Scenario Type, a set of tasks, and security groups. Profiles form a hierarchy — CubeRoot at the top, with Review, BaseInput, ParentInput, and Default profiles beneath it. |
| Scenario Type | Determines which Workflow Profile tree governs a given scenario. Actual, Budget, Forecast, and other scenario types each have their own profile hierarchy. |
| Time | The period being processed (e.g., 2024M6). Workflow status is tracked per entity per time period, so January and February for the same entity can be in completely different states. |
| WorkflowUnitPk | The primary key identifying a single workflow unit — a specific Profile + Scenario + Time combination. This is the most granular level at which status and locking are tracked. |
| Certification | The final sign-off that confirms data is complete and reviewed. Once certified, data is locked and the workflow unit's status reflects that no further changes are expected. |
| Locking | Prevents further changes to data. Locking can be applied directly at the workflow unit level or inherited from parent entities in the hierarchy. |
End-User Perspective
When an end user opens a Workflow in OnePlace, they see a task bar — a horizontal strip of steps they must complete in sequence. A typical task bar might show Import → Validate → Load → Process → Confirm → Certify. Each step has a color-coded status:
| Color | Meaning |
|---|---|
| Blue | Not yet started or currently in progress |
| Green | Completed successfully |
| Red | Completed with errors that must be resolved before advancing |
The user clicks each step in sequence. Clicking Import triggers the data pipeline; clicking Certify locks the data and signals that the entity's numbers are final. The specific steps shown on the task bar depend on the Workflow Name configured on the entity's Workflow Profile — different profiles can present different task sequences for different entities or scenario types.
Workflow and Scenario Types
Each Scenario Type can have its own Workflow Profile tree. This means the steps, security, and entity assignments for Actual close can differ entirely from those for Budget entry — even though both use the same dimension structures.
The mechanism that enables this is
SuffixForVaryingWorkflowByScenarioType. This application-level setting appends a suffix to profile names when the engine resolves which profile governs a given scenario. For example, if the suffix for the Budget scenario type is _BUD, the engine looks for a profile named Revenue_BUD instead of Revenue when processing Budget data.Cube Configuration
When an application has multiple cubes, the
IsTopLevelCubeForWorkflow flag designates which cube's entity dimension drives the Workflow hierarchy. Only one cube per Scenario Type can be the top-level cube for workflow. This is configured on the Cube Properties panel in the application.The top-level cube matters because the Workflow Engine builds its entity tree from that cube's entity dimension. If you have a Consolidation cube and a Planning cube, you choose which one owns the workflow hierarchy — typically the Consolidation cube, since it contains the full legal entity structure.
Related Content
- Workflow Profile Hierarchy — next guide in the series
- Scenario Types and Cube Dimensions — how Scenario Types affect cube structure
- IVL Overview — how data loading fits into the workflow pipeline