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 parent unless explicitly overridden.
  • If a BaseInput profile has no WorkflowExecutionGroup set, it inherits from the CubeRoot or Review profile above it.
  • Explicit assignment on a child profile overrides inheritance completely — it does not merge with the parent's group.
  • If a parent has WorkflowExecutionGroup = "DataLoaders" and a child sets WorkflowExecutionGroup = "RegionalLoaders", only members of "RegionalLoaders" can execute tasks on the child. Members of "DataLoaders" have no implicit access to the child.
⚠️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