A Workflow Profile is the basic building block of a Workflow Management Structure. Another way to think about a Workflow Profile is a task list that should be performed by a group of users in relation to a group of Entities. Eight different types of Workflow Profiles are available for use within a Workflow hierarchy. Each Workflow Profile type and its role within a Workflow hierarchy is described below.
Cube Root Profile Type
A Cube Root Profile should be thought of as the definition of a Workflow hierarchy for an entire Cube or a suffix group defined by the Cube. (See the preceding section on Cubes and Workflow). As a result, to create a new Cube Root Profile there must be a Cube defined in the Analytic Model marked as Is Top Level Cube For Workflow = True.
Default Profile Relationship
When a new Cube Root Profile is created, the Workflow Engine will automatically create a matching Default Input profile that is prefixed with the Cube Root Profile name (e.g. Corporate_Default). A Default Input profile is required for each Workflow hierarchy and it cannot be deleted. The job of the Default Input is to establish the default relationship between the Workflow structure and the Entity Members within the Cube the Cube Root Profile was created to control.
Controlling Workflow States
Cube Root Profiles have a predefined Workflow used to control the state of the Workflow Management Structure (Open / Closed). Cube Root Profiles are used as a mechanism to control the state of the entire Workflow hierarchy for a given Scenario and time because they represent the top element of a Workflow hierarchy.
Open State
The Workflow is available for usage and locking is controlled at the individual Workflow Profile level. In addition, all Workflow hierarchy structure information is read from the current Workflow hierarchy as it reads the Workflow Profiles management screen. This also means the Workflow hierarchy is accessed from memory (cache) rather than being read from the database which provides very fast read performance.
Closed State
The act of closing a Workflow hierarchy triggers the Workflow Engine to place a high-level lock on the Workflow. This means individual Workflow Profile lock status values do not matter, and the Workflow level will display a 
to indicate a closed Workflow. In addition, the Workflow Engine will take a snapshot of the current Workflow hierarchy structure being managed from the Workflow Profiles management screen. It will store it in a historical audit table for the Scenario and time being closed. This also means the Workflow hierarchy is not accessed from memory (Cache) as would be the case with a Workflow in an open state. A closed Workflow must be read from the database rather than memory because it is considered a point in time snapshot stored in a historical table. This is a performance penalty noticed when reading the entire closed Workflow hierarchy for a Scenario and time. Workflow hierarchies should only be closed if major changes are being made to the Workflow hierarchy and the structure of a Cube and historical hierarchy relationships need to be preserved.
Review Profile Type
Review Profiles are best thought of as checkpoints in the Workflow hierarchy structure. This type of profile does not have a direct relationship to an Entity Member or Origin Member. However, Review Profiles can have Calculation Definitions assigned to them, so that Cube calculations can be ran in a controlled manner during the Workflow sign-off process.
Named Dependents
Review Workflow Profiles have a unique ability to establish a dependency on the status of Input Parent Profiles that are not their direct descendant in the Workflow hierarchy structure. This concept is referred to as a Named Dependent relationship and was developed to accommodate situations where a single Input Parent Profile loads data for many legal Entities that have very different responsibility structures from a sign-off perspective. This situation is very common when an organization utilizes a Shared Services infrastructure strategy.
Creating a Named Dependent
The screenshot below demonstrates an example of the Canada Clubs Review Profile establishing a Workflow dependency on the Eagle Drivers Input Parent Profile, even though the Eagle Drivers Input Parent is not a descendent of Canada Clubs.
Input Parent Profile Types
Input Parent Profile types are special profile types because they are the point where a relationship is formed between the Workflow Management Structure and an Entity Member. All Input Parent Profiles types share the common purpose of organizing different types of data input used to feed an Entity. This is accomplished through the use and control of dependent profiles called Input Children.
All Input Parent Profiles must have at least one Input Child of each type (Import, Form and Adjustment). This requirement exists because of the relationship between Input Child Profiles and the Origin Dimension Members. Input Child Profiles can be thought of as a specialized extension of the Input Parent with added intelligence and control features particular to data updating.
Default Input
Default Input Parent Profiles are special because they cannot be created directly. They are automatically created whenever a Cube Root Profile is created.
Unassigned Entities
The primary purpose of the Default Input Profile type is to serve as the initial relationship between the Entities belonging to a Cube Root Profile and the Workflow hierarchy. Entities cannot be explicitly assigned to a Default Input Profile. Any Entity Member under the Cube with which the Default profile is associated and is not explicitly assigned to a Parent Input Profile or Base Input Profile, is implicitly assigned to the Default Profile.
Parent Input
Parent Input Profiles are used to allow adjustments to Parent Entities in the Cube. Adjustments to a Parent Entity are only allowed via Forms or AdjInput Members of the Origin Dimension. Consequently, Import Child Profiles are not allowed to be used with a Parent Input Profile. The Workflow Engine will automatically create an Import Child for each Parent Input Profile, but the Import Child will be forced to be inactive (Profile Active = False).
Assigned Entities
The primary purpose of the Parent Input Profile type is to establish a relationship between Parent Entities that require the ability to accept adjustments and the Workflow hierarchy. Parent Entities do not need to be explicitly assigned to a Parent Input Workflow Profile unless the Parent Entity requires the ability to be adjusted. Most Parent Entities exist as unassigned Entities and therefore are controlled by the Default Input Profile.
Base Input
Base Input Profiles are used to control all methods of data entry for Base Entities in the Cube. This is the most common Workflow Profile type and can be thought of as the workhorse of data update management. Base Input Parents define the Entities that can be updated, the Cube being targeted, and all the Import Child types that will participate in the input scheme.
Assigned Entities
The primary purpose of the Parent Input Profile type is to establish a relationship between Base Entities that need to receive data from an external source and the Workflow hierarchy.
Input Child Profile Types
Input Child Profile types will always be base Members of a Workflow hierarchy and can only be children of one of the three types of Input Profiles: Default, Parent or Base.
Origin Dimension Relationship
Input Children are mapped directly to Origin Members in the Analytic Cube to create a control mechanism between the Workflow hierarchy and the Cube. This linkage enables the Workflow Engine to control the importing, form data entry, adjustment (journal) data entry and data locking processes for one or more Entities.
Controlling Input Channels
The relationship between Origin Members and the Input Child Profiles that map to them enables the Workflow hierarchy to be configured in a way that allows/disallows certain input channels for the Entities assigned to the Input Parent Profile. By setting the Profile Active switch, an entire channel of input can be enabled/disabled.
For example, if a Forms Input Child has the Profile Active set to False, and there are no other active Input Child siblings of the type Form, data entry forms and Excel (SetCells Function or Cube Views) cannot be used to set data cell values for the Entities assigned to the Input Parent Profile of the Forms Input Child. The same technique can be used to enable/disable Import and Adjustment input types.
Import Child
An Import Child defines and controls how data is imported into the Cube (See Data Loading for more details). Each Import Child is bound to the Data Source and Transformation Rule Profile which will define its Workflow behavior during the Import Workflow Step.
Import Child Origin Mapping
The Workflow Engine enforces a relationship between Import Child Profile types and the Import Member of the Origin Dimension. This means, when loading data, the Origin Member will be forced to the value Import.
Forms Child
A Form Child defines and controls how data is manually entered in the Cube. Each Form Child is bound to an Input Forms Profile that will define its Workflow behavior during the Input Forms Step.
Form Child Origin Mapping
The Workflow Engine enforces a relationship between Form Child Profile types and the Forms Member of the Origin Dimension. This means when creating data entry forms, the Origin Member must be set to Forms or the data cell will appear as read only.
It is possible to use a data entry form to update the AdjInput Member of the Origin Dimension, but this requires the account being updated to have its Adjustment Type set to Data Entry rather than the default value of Journal.
Adjustment Child
A Journal Child defines and controls how data is entered via journal into the Cube. Each Form Child is bound to a Journal Template Profile that will define its Workflow behavior during the Input Journals Step.
AdjInput Child Origin Mapping
The Workflow Engine enforces a relationship between Adjustment Child Profile types and the AdjInput Member of the Origin Dimension. This means when creating journal entries, the Origin Member will be forced to the value AdjInput.
Workflow Entity Relationship
The relationship between Workflow Profiles and Cube Entities creates a powerful asset that can act as leverage across many areas of the Workflow experience. By performing the one-time setup process of binding Entities to specific Workflow Profiles, the OneStream Workflow Engine can make this relationship information available to the application designer in many areas of the product. This means Workflow control structures and data entry mechanisms can be designed using abstract methodologies that refer to the current Workflow Unit value, which in turn can be resolved to a list of associated Entities.
Workflow Entity Relationship Member Filter Examples
The primary way the Workflow Entity relationship is used is through analytic Member Filters.
E#Root.WFProfileEntities
When used in a Member Filter, this expression returns all Entities associated with the selected Workflow Unit.
E#Root.WFCalcuationEntities
When used in a Member Filter, this expression returns all Entities defined as part of the Calculation Definitions for the selected Workflow Unit.
E#Root.WFConfirmationEntities
When used in a Member Filter, this expression returns all Entities defined as part of the Calculation Definitions when the Confirmed Switch is set to True for the selected Workflow Unit.
Multiple Input Workflow Profiles per Type
An application can have multiple input Workflow Profiles of the same type (Import, Forms, Journals) within each period. This is useful when multiple source systems are feeding the same Entities that need separate Data Sources in XF. It is also convenient when multiple form groups need to be completed by different groups of people. People only see and work on what they have access to because different access groups are created for each. The example below shows a budget where there is one Import Workflow Profile and eight different Form data entry channels that can be assigned to different groups of people. Each of these input channels can have multiple Forms.
If there are multiple Import Workflow Profiles, it automatically handles clearing and merging data. For example, if there are two Import Workflow Profiles and import has already performed on one of them, when the second import is performed and the user clicks Load, all the target Entities are cleared. The two import data sets are merged, and a replace-style load is made to the financial model.
Load YTD and MTD in the Same Workflow Profile
During the configuration of a Workflow Profile for a Scenario, the Workflow may require the submission of YTD data in one Origin and MTD/Periodic data in another Origin within the same Workflow Profile. If the Default View for the Scenario is configured as YTD, the Origin submitting MTD/Periodic data needs to be configured appropriately for it to behave as MTD/Periodic.
Select the Workflow Profile to configure, expand the Workflow Profile, and then select the Origin to be configured. In this example, Houston.Import is YTD and Houston.Sales Detail is MTD.
Next, choose the Scenario type where this behavior is needed. Select (Default) if this behavior is required for all Scenario Types.
Select Integration Settings to change the following properties:
As a result, the Flow Type Accounts will be processed as Periodic rather than YTD upon data submission or when no data is loaded for Flow Accounts. The Balance Accounts are forced to be processed as YTD upon data submission.
