Workflows

Workflow Security

Workflow security controls who can see, execute, and certify each Workflow Profile. Security is enforced through named Security Groups assigned at the profile level. These groups work together with the OneStream identity layer (Users, Groups, Roles) to create a layered permission model. A user who is not a member of the relevant group simply cannot perform the action — the UI disables the corresponding buttons and the API rejects the call.

Profile-Level Security Groups

Every Workflow Profile exposes four security group properties. Each one controls a different surface area of interaction with the profile.
Security GroupControlsTypical Assignment
AccessGroupWho can see the profile and its entities in OnePlaceAll users who need visibility into the entity's workflow status
MaintenanceGroupWho can modify the profile's configuration in the Application areaAdministrators only
WorkflowExecutionGroupWho can execute workflow tasks (Import, Load, Process) for this profileData loaders, power users
CertificationSignOffGroupWho can certify (sign off) on the profile's dataControllers, managers with sign-off authority
The most common pair to configure is WorkflowExecutionGroup and CertificationSignOffGroup. AccessGroup defaults to broad visibility, and MaintenanceGroup is typically restricted to the admin team that manages application configuration.

Journal-Specific Groups

When the profile has an Adjustment child type configured, three additional security groups become available. These control the journal entry lifecycle independently from the main workflow tasks.
Security GroupControls
JournalProcessGroupWho can create and process journal entries
JournalApprovalGroupWho can approve journal entries (if approval workflow is enabled)
JournalPostGroupWho can post approved journals to the cube
ℹ️Info
Journal groups are only relevant when the profile has an Adjustment child type. They have no effect on Import or Forms data entry.

Security Inheritance

Workflow Profiles form a hierarchy (CubeRoot → Review → BaseInput), and security groups follow that hierarchy with a simple inheritance rule:
  • Child profiles inherit security from their ancestors; a child-level assignment adds to (does not cancel) inherited rights.
  • If a BaseInput profile has no WorkflowExecutionGroup set, it inherits from the CubeRoot or Review profile above it.
  • Explicit assignment on a child profile adds the group that can execute at that node — it does not strip the ancestor's rights.
  • If a parent has WorkflowExecutionGroup = "DataLoaders" and a child sets WorkflowExecutionGroup = "RegionalLoaders", members of "RegionalLoaders" can execute tasks on the child — and members of the ancestor's "DataLoaders" group retain execution authority over that child too. Inherited WorkflowExecutionGroup rights from an ancestor apply to all descendants regardless of the descendant's own assignment.
⚠️Warning
Set security explicitly on every BaseInput profile rather than relying on inheritance. Implicit inheritance makes it difficult to audit who has access to what, and a change to the parent profile can silently grant or revoke access across many entities.

Common Security Patterns

Pattern 1: Separating Loaders from Certifiers

The most fundamental pattern — ensure the people loading data cannot also certify it.
  • WorkflowExecutionGroup = "DataLoaders" — the team that imports and processes data
  • CertificationSignOffGroup = "Controllers" — a different group that reviews and certifies
  • This separation of duties is a core internal control. Auditors expect to see different groups in these two fields.

Pattern 2: Regional Review with Central Certification

For organizations with regional teams that load data but a central finance team that certifies:
  • Review profiles for each region with AccessGroup = the regional team
  • BaseInput profiles under each Review with WorkflowExecutionGroup = regional data loaders
  • CertificationSignOffGroup on Review profiles = "CentralFinance" — only the central team can certify
This gives regional teams full control over data entry while reserving final sign-off for central finance.

Pattern 3: Read-Only Observers

Allow stakeholders to monitor workflow progress without being able to act:
  • AccessGroup includes the "Observers" group so they can view status in OnePlace
  • WorkflowExecutionGroup and CertificationSignOffGroup exclude them — they can see but not act
💡Tip
OneStream evaluates security groups at runtime. If a user is not in the WorkflowExecutionGroup for a profile, the Import/Load/Process buttons are disabled in the UI — the user can see the workflow status but cannot execute any tasks.

Related Content