Workflows

Workflow Profile Hierarchy

Updated March 7, 2026

Workflow Profiles form a tree that mirrors — but does not duplicate — the Entity dimension hierarchy. Each profile type serves a distinct purpose: controlling workflow state, aggregating certification status, or enabling data entry for specific entities. Understanding the profile hierarchy is essential before configuring any workflow. For the broader workflow architecture, see Workflow Engine Overview.

Profile Hierarchy

diagramWorkflow Profile Hierarchy

Loading diagram...

The CubeRoot profile sits at the top of every workflow — it is auto-created when the Workflow is initialized. Below it you add Review, BaseInput, and ParentInput profiles to match your organizational structure. The Default profile catches any entity not explicitly assigned to another profile, acting as a fallback during initial setup.

CubeRoot Profile

The CubeRoot profile is the root node of the workflow tree. There is exactly one CubeRoot per Cube per Scenario Type.

Automatically created when you initialize a Workflow for a given Cube and Scenario Type — you cannot add or delete it manually.
Controls the overall Open/Closed state of the workflow for a time period. When the CubeRoot is Closed, no entity under it can accept data input regardless of its own profile status.
AccessGroup and MaintenanceGroup properties provide top-level security — they control who can view and who can administer the entire workflow tree.
Auto-creates a Default child profile on initialization, so the workflow is immediately functional for all entities.

ℹ️Info

Opening or closing the CubeRoot is the master switch for the entire workflow. Close it at period-end to lock all entities at once, regardless of individual profile states.

Default Profile

The Default profile is the fallback for entities not assigned to any specific BaseInput or Review profile. It always exists as a direct child of the CubeRoot.

Catches unassigned entities — any entity in the dimension that is not explicitly mapped to a BaseInput or Review profile falls under Default.
Useful during initial setup — you can get the workflow running before configuring dedicated profiles. Entities work with Default until you create and assign specific profiles for them.
Supports the same workflow actions (certify, lock, etc.) as other profile types, but applies them uniformly to all unassigned entities.

💡Tip

In production, assign every entity to a specific profile. Relying on Default makes it hard to apply entity-specific security, workflow names, and certification rules. Default should be empty in a mature configuration.

Review Profile

Review profiles are checkpoint nodes in the hierarchy. They aggregate status from child profiles below them and do not directly accept data input.

Roll up certified/locked status — a Review profile shows the combined certification state of its children. It cannot be certified until all children are certified.
Used for regional or divisional oversight — for example, a "North America" Review profile with BaseInput children for US, Canada, and Mexico. The regional controller sees the rollup status and certifies at the regional level once all countries are done.
Do not accept data entry — Review profiles have no Import, Adjustment, or Forms children. Their sole purpose is status aggregation and certification gating.

Named Dependents for Shared Services

Review profiles can define Named Dependents — references to other profiles that must be certified before this review node can be certified. This is used for shared service entities that cut across the organizational hierarchy.

For example, a Corporate Allocations BaseInput profile might need to certify before the Regional Review can certify. You add Corporate Allocations as a Named Dependent on the Regional Review profile, and the system enforces the sequencing automatically.

ℹ️Info

Named Dependents create cross-branch dependencies in the workflow tree. Use them sparingly — each dependency adds a certification gate that blocks downstream sign-off.

BaseInput Profile

BaseInput profiles are the workhorse of the workflow system. This is where entities are assigned for actual data entry.

Entity Assignment — each BaseInput profile is assigned one or more entities from the dimension. An entity can belong to only one BaseInput profile per Workflow.
Input child types — BaseInput profiles contain child configurations for Import, Adjustment, and Forms that control how data enters the system. These are covered in detail in Input Profiles and Child Types.
Workflow Name — controls which tasks appear on the task bar for assigned entities. Users see only the tasks relevant to their entities.
Security groups — four groups control access at the profile level:

Group	Purpose
AccessGroup	Users who can view data for assigned entities
MaintenanceGroup	Users who can modify the profile configuration
WorkflowExecutionGroup	Users who can run workflow actions (load, calculate, etc.)
CertificationSignOffGroup	Users who can certify or sign off the profile

⚠️Warning

Each entity can be assigned to only one BaseInput profile within a Workflow. If you assign an entity to a second profile, it is removed from the first. Plan your entity-to-profile mapping before building the tree.

ParentInput Profile

ParentInput profiles enable data entry at a consolidated (parent) level without affecting child entity data. They are less common than BaseInput profiles and are used in specific consolidation patterns.

Attached to a parent entity in the hierarchy — for example, a holding company entity that needs top-side adjustments or corporate eliminations.
Allows consolidated-level data entry — users can enter adjustments that apply at the parent level, such as intercompany eliminations or management adjustments, without modifying the child entity submissions.
Does not replace BaseInput — child entities still have their own BaseInput profiles for regular data entry. ParentInput adds an additional entry point at the parent level.

💡Tip

Use ParentInput only when you need parent-level adjustments that are separate from the standard consolidation process. For most applications, BaseInput profiles on leaf entities are sufficient.

WorkflowProfileTypes Enum

The platform represents profile types as an enum. This is useful when working with profiles programmatically in Business Rules.

Enum Value	Integer	Description
CubeRoot	0	Top-level profile — one per Cube per Scenario Type
Default	1	Fallback profile for unassigned entities
Review	2	Status aggregation and certification checkpoint
BaseInput	3	Data entry profile — the workhorse
ParentInput	4	Parent-level adjustment profile

Design Guidance

When designing your workflow profile hierarchy, follow these principles:

Start with CubeRoot + Default, then add BaseInput profiles as you assign entities. Get the basic workflow running before adding complexity.
Use Review profiles when you need sign-off at a regional or divisional level. If you do not need a multi-level certification process, you can skip Review profiles entirely and have BaseInput profiles directly under CubeRoot.
Use ParentInput only when parent-level adjustments are required. Most workflows do not need ParentInput profiles — they are specific to consolidation scenarios with top-side entries.
Keep the hierarchy as flat as possible. Deep nesting adds complexity without benefit. A CubeRoot with 20 BaseInput children is simpler and easier to maintain than a deeply nested tree with multiple Review layers.
Match the profile hierarchy to your certification workflow, not your entity hierarchy. The entity dimension may have six levels of nesting, but your certification process may only need two levels (entity-level certification and regional sign-off). Build the profile tree to match the certification flow.

Workflow Engine Overview — architecture and lifecycle of the Workflow engine
Input Profiles and Child Types — Import, Adjustment, and Forms configuration within BaseInput profiles
Workflow Security — security groups, access control, and certification permissions