Workflows

Input Profiles and Child Types

BaseInput and ParentInput profiles define how data enters the cube. While the Workflow Profile Hierarchy determines which entities are assigned to which profiles, the child types on those profiles determine the available data entry channels. Each profile can contain up to three child types — Import, Adjustment, and Forms — representing file-based loads, journal entries, and dashboard-based input respectively. This guide covers each child type, the workflow names that control task sequencing, and the execution model behind data loads.

Import Child Type

The Import child (enum value 50) is the primary channel for automated data loads. It binds a Data Source and a Transformation Rule Profile to the workflow, enabling the Import-Validate-Load (IVL) pipeline for the assigned entities.
When a user clicks Import on the task bar, the system executes the configured data source — pulling data from a flat file, a database connector, or an API — then applies the transformation rules to map source values to cube dimension members.
Key configuration properties:
PropertyPurpose
Data Source NameIdentifies the Stage data source (file parser, connector, or business rule connector) that supplies raw records.
Transformation Rule ProfileNames the profile containing the mapping rules that convert source columns into cube intersections.
💡Tip
A single BaseInput profile can have one Import child. If an entity needs data from multiple sources, use a Connector Business Rule to merge or stage the files before the parser runs, or configure multiple data sources at the Stage level and reference the combined output.

Adjustment Child Type

The Adjustment child (enum value 51) enables journal entry input for the assigned entities. Journals allow manual adjustments, reclassifications, top-side entries, and eliminations — any scenario where data needs to be entered or modified outside the automated import pipeline.
Journals follow a multi-step lifecycle: create, process, approve, post. Security for each step is governed by dedicated journal groups configured on the Adjustment child:
Security GroupControls
JournalProcessGroupWho can create and process journal entries for the entity.
JournalApprovalGroupWho can approve processed journals before they are posted.
JournalPostGroupWho can post approved journals, writing the values into the cube.
ℹ️Info
Journal security groups are separate from the workflow step security groups (Confirm, Certify). A user might have permission to create journals but not to certify the overall workflow — or vice versa.

Forms Child Type

The Forms child (enum value 52) binds a Dashboard Profile to the workflow, exposing a form-based data entry interface to users. When a user clicks the Forms task on the task bar, the system opens the configured dashboard, which typically contains input grids, dropdowns, and validation logic.
Forms are the primary data entry method for:
  • Budget input (revenue drivers, headcount planning, capital expenditures)
  • Forecast adjustments and assumption entry
  • Manual data collection where structured forms are preferred over spreadsheet-style imports
Configuration is straightforward — specify the Dashboard Profile name on the Forms child. The dashboard itself defines the layout, input cells, validation rules, and any business rule logic that runs on save.
💡Tip
Forms and Import are not mutually exclusive. A common pattern for Budget scenarios is to use Forms for manual driver entry and Import for loading baseline data or prior-year actuals into the same entity.

Child Type Reference

Child TypeEnum ValueData Entry MethodKey Configuration
Import50File upload / ConnectorData Source, Transformation Rule Profile
Adjustment51Journal entriesJournal security groups
Forms52Dashboard-based inputDashboard Profile name

Workflow (Task Sequence) Configuration

Each input child (Import, Forms, Adjustment) selects its own Workflow — the ordered set of task-bar steps for that origin. OneStream ships a large catalog of predefined workflows, grouped by origin:
  • Import — Import → Validate → Load, optionally followed by Process, Confirm, Certify. A Direct load variant loads straight to the cube without transformation.
  • Forms — Form Input, optionally with Pre-Process, Process, Confirm, Certify.
  • Adjustment (Journals) — Journal Input, optionally with Process, Confirm, Certify.
A profile's task bar shows the combined steps of all of its active children. A BaseInput profile with both an Import child and a Forms child presents both origins' steps together — there is no single "Import + Forms" workflow; each origin carries its own.
OriginExample step combinations
ImportImport, Validate, Load · +Process · +Confirm · +Certify
Direct (Import)Load (no transformation) · +Process / Confirm / Certify
FormsForm Input · +Pre-Process · +Process · +Confirm · +Certify
JournalJournal Input · +Process · +Confirm · +Certify
ℹ️Info
Because each Scenario Type has its own Workflow Profile hierarchy, the same entity can run a full "Import, Validate, Load, Certify" workflow for Actual and a simpler one for Budget. See the Workflow Engine Overview.

Data Load Execution Sequence

When a user clicks Import, the source data is parsed and transformed into the Stage engine. The cube data is not cleared at this point — the clear happens as part of the Load step (clear-then-write), so a failed parse or transform does not wipe existing cube data.
diagramData Load Execution Sequence

Loading diagram...

  1. Parse — Execute the configured Data Source (file parser, connector, or connector business rule) to read raw source records into the Stage Engine.
  2. Transform — Apply the Transformation Rule Profile to map source values to dimension members (account mappings, entity lookups, flow derivations).
  3. Validate — Run transformation validation (unmapped values, rejected records) and intersection validation (invalid member combinations, security violations).
  4. Load — Clear the existing data for the target intersection and write the validated records into the Finance Engine cube. The clear and write happen together during Load, so it is a full replace but the cube is not left empty if an earlier step fails.
⚠️Warning
The clear is part of the Load step, not a first step before parsing. Because parsing and transformation happen in Stage before anything is cleared, a failure during parse or transform leaves the existing cube data intact — the entity is only re-based when Load actually runs.

Controlling Input Channels

Each child type has an Active toggle that enables or disables that data entry channel without removing its configuration.
Setting a child to Inactive:
  • Hides the corresponding task bar step from users
  • Prevents programmatic execution of that channel through business rules
  • Preserves all configuration (data source bindings, dashboard profiles, journal groups) so the channel can be reactivated later
This is useful for temporarily disabling imports during system maintenance, closing off form entry after a budget deadline, or deactivating journal input during close periods where only automated loads should run.
💡Tip
You can control the Active flag programmatically through BRApi, enabling scenarios like automatically disabling Forms input after a submission deadline or toggling Import channels on and off as part of a scheduled workflow.

Related Content