Many names, much confusion, and it’s all rather important

It has been your author’s observation that the glue that holds OneStream applications together – Workflow – is a victim of terminological inexactitude. No, not that odious euphemism, but instead the common usage of just one term – “Workflow Profile” – for the four (arguably five) different Workflow Profile types. When we OneStream practitioners use the same word to mean many things, we confuse ourselves, make mistakes, and generally make everyone who touches the application unhappy. Happy is more fun.

To avoid that state of Workflow-induced despair, we need a commonly agreed upon taxonomy and then we must use it. Happily, OneStream has created those Workflow types and definitions (they could not do otherwise) so the path to understanding then is to get all OneStream practitioners to comprehend and adhere to those taxonomical definitions. Working with a tool as sophisticated as Workflow requires terminological exactitude so that we all understand what on earth we’re talking about.

Four, just four

As noted, there are four main Workflow types: Cube Root Workflow Profile, Default Workflow Profile, Workflow Profile, and Workflow Child Profile.

How hard could it possibly be? Let’s find out.

A note

This post is not a comprehensive guide to Workflow. For that, see the OneStream Design and Reference Guide and its Workflow Guides section.

Cube Root Workflow Profile

The Cube Root Workflow Profile is defined at the Cube Level by Scenario Type via Scenario Suffixes. Think of using Scenario Suffixes at the Cube level as a sort of extended (OneStream uses the term “varying”) Workflow as it allows your application to segregate Workflow by Scenario Type.

In the above example, the Scenario Type Suffixes are Actual and Forecast. The values are arbitrary – they could be Potato or Happy or more likely the ones shown or Budget or LRP. Try to use something meaningful.

Missing Scenario Types

Scenario Types are good practice because they allow explicit assignments of an Entity to more than one Workflow Profile (more anon on this term). Even if there is no immediate need for them, applications have a way of growing and it’s best to have Scenario Types in place when they do. There’s no need to assign Suffixes to each Scenario Type, just one will do as a start and then expand as many times as needed.

Naming confusion

A note about Scenario Types – don’t conflate a Scenario named “Plan” with a Scenario Type of “Plan” as the only logical and functional link one you, Gentle Reader, should define in the tool.  Although a “Plan” Scenario Type can certainly have a Suffix of “Plan” and be used in the “Plan” Scenario, it isn’t required.  This sort of identical naming convention, while appealing on its face, breaks down if there is more than one Scenario that logically shares a Scenario Type which is often the case in planning applications.  Whew.

As with everything OneStream, there are many ways to approach a requirement, none of which are exactly wrong but some of which are not quite as good as others. Your application’s needs will dictate what is best.

Using the example below of three Scenario Types (Actual, Forecast, and Plan) with two different Scenario Suffixes (Actual and Forecast), when a new Cube Root Profile is created, the two Scenario Types of Actual and Forecast appear; the Workflow Scenario Type Suffix defines the Workflow Cube Root Profiles, not the Scenario Types themselves.

Creating a Cube Root Workflow Profile

The naming convention is CubeName_ScenarioType.

Clicking on either choice will create the Cube Root Workflow Profile Name. For the purposes of this post, only Sample_Forecast will be used.

It’s easy to identify in the Workflow Profile editor hierarchy as it’s at the very tippy top and has a cube icon to the left of the name:

Default Workflow Profile

Once the Cube Root Workflow Profile is created, the Default Workflow Profile Sample_Forecast_Default appears automatically.

A Default Workflow Profile connects the Cube’s Entities and Workflow itself. All Entities are by default assigned to the Workflow – note that the Entity Assignment property sheet does not exist in the Default Workflow Profile.

Some of its salient characteristics are:

1. It is named CubeName_WorkflowSuffix_Default.
2. It joins Cube Entities to Workflow.
3. It cannot be deleted.
4. Only Administrators should be able to see it.

As with all Workflow Profiles, the Workflow Child Profiles of Import, Forms, and Adj appear below the Workflow Profile name.

A click on the Import Child Profile (this is just illustrative – don’t actually use the Default Workflow Profile) shows that two Scenario Types are available: Forecast and Plan. These are the Scenario Types that share the Workflow Suffix “Forecast”.

Scenarios with Scenario Types

The Plan Scenario has a Scenario Type of “Forecast”. (Remember what I said about the potential for confusion? Here it is.)

Scenario Types are linked to the Scenario Type property in the Scenario itself. This relationship defines the Scenarios in OnePlace. Whew, again.

All you really have to know is that if a Cube’s Workflow has defined Scenario Types, the Workflow is extended and a Scenario tagged with that Scenario Type is now part of that Workflow; only Scenarios with that Scenario Type will appear in OnePlace.

Whew, again and again.

Workflow Profile

Workflow Profile Types

There are three Workflow Profile Types: Review, Base Input, and Parent Input.

As this post is written by Mr. Planning, I’ll confidently state that Base Input is the overwhelmingly most used type in planning applications although of course Review and Parent Input are used as well; Consolidations applications are far more likely to use all three types As the purview of this post is not All Things Workflow but instead Workflow terminology, only Base Input will be examined.

Workflow Child Profile

We have now almost reached the end of our Workflow taxonomical journey.

Note that by default, the Workflow Child Profiles of Import, Forms, and Adj have been automatically created.

Workflow Child Profile types are tied to the Origin dimension, with a fairly logical grouping of Import with Import, Forms with Forms, and Adj with AdjInput.

That’s it – we are at the bottom of the Worfklow Profile tree with Workflow Profile as the most atomic.

There is one more we-call-it-Workflow-Profile-but-really-it’s-something-else element: Workflow Names.

Workflow Names

Workflow Names are confusingly called “Default Workflow” when a Workflow Child Profile is created:

They are called Workflow Names within a Workflow Child Profile:

Think of Workflow Names as the actions that drive Workflow. Given that the property sheet for a Workflow Child Profile uses “Workflow Names”, it seems most logical to use that term when referring to the many, many, many actions (almost 60) they support. Whew, one last time.

As an example, in the Workflow Child Profile Import, I can use the traditional Import, Validate, Load Workflow Name to load data:

Or I can use Direct and change the way data is loaded into the Cube:

Do we have unanimity? Close to it? We should.

Workflow is the core structure OneStream application data processing. Workflow is sophisticated and powerful. Its potential is great, as is its potential to go sideways if discussed and thought about incorrectly.

To use it correctly, we must mean what we say by using the right terms in the right place.

Thus:

1. Cube Root Workflow Profiles are the topmost level of the Workflow hierarchy. They are tied to Workflow Types. Scenarios that have a matching Scenario Type are visible in OnePlace.
2. The Default Workflow Profile is automatically generated when a Cube Root Workflow Profile is created. It bridges Cube Entities and Workflow. Do not use it.
3. Below the main Cube Root Workflow Profile parent, Workflow Profiles join data, metadata, and users.
4. Workflow Child Profiles are where users interact with Workflow be it data loads, forms, or adjustments via Workflow Name action types.

That’s it.

Be seeing you.[vc_row disable_element=”yes”][vc_column][vc_column_text]

Many names, much confusion, and it’s all rather important

It has been your author’s observation that the glue that holds OneStream applications together – Workflow – is a victim of terminological inexactitude. No, not that odious euphemism, but instead the common usage of just one term – “Workflow Profile” – for the four (arguably five) different Workflow Profile types. When we OneStream practitioners use the same word to mean many things, we confuse ourselves, make mistakes, and generally make everyone who touches the application unhappy. Happy is more fun.

To avoid that state of Workflow-induced despair, we need a commonly agreed upon taxonomy and then we must use it. Happily, OneStream has created those Workflow types and definitions (they could not do otherwise) so the path to understanding then is to get all OneStream practitioners to comprehend and adhere to those taxonomical definitions. Working with a tool as sophisticated as Workflow requires terminological exactitude so that we all understand what on earth we’re talking about.

Four, just four

As noted, there are four main Workflow types: Cube Root Workflow Profile, Default Workflow Profile, Workflow Profile, and Workflow Child Profile.

How hard could it possibly be? Let’s find out.

A note

This post is not a comprehensive guide to Workflow. For that, see the OneStream Design and Reference Guide and its Workflow Guides section.

Cube Root Workflow Profile

The Cube Root Workflow Profile is defined at the Cube Level by Scenario Type via Scenario Suffixes. Think of using Scenario Suffixes at the Cube level as a sort of extended (OneStream uses the term “varying”) Workflow as it allows your application to segregate Workflow by Scenario Type.

In the above example, the Scenario Type Suffixes are Actual and Forecast. The values are arbitrary – they could be Potato or Happy or more likely the ones shown or Budget or LRP. Try to use something meaningful.

Missing Scenario Types

Scenario Types are good practice because they allow explicit assignments of an Entity to more than one Workflow Profile (more anon on this term). Even if there is no immediate need for them, applications have a way of growing and it’s best to have Scenario Types in place when they do. There’s no need to assign Suffixes to each Scenario Type, just one will do as a start and then expand as many times as needed.

Naming confusion

A note about Scenario Types – don’t conflate a Scenario named “Plan” with a Scenario Type of “Plan” as the only logical and functional link one you, Gentle Reader, should define in the tool.  Although a “Plan” Scenario Type can certainly have a Suffix of “Plan” and be used in the “Plan” Scenario, it isn’t required.  This sort of identical naming convention, while appealing on its face, breaks down if there is more than one Scenario that logically shares a Scenario Type which is often the case in planning applications.  Whew.

As with everything OneStream, there are many ways to approach a requirement, none of which are exactly wrong but some of which are not quite as good as others. Your application’s needs will dictate what is best.

Using the example below of three Scenario Types (Actual, Forecast, and Plan) with two different Scenario Suffixes (Actual and Forecast), when a new Cube Root Profile is created, the two Scenario Types of Actual and Forecast appear; the Workflow Scenario Type Suffix defines the Workflow Cube Root Profiles, not the Scenario Types themselves.

Creating a Cube Root Workflow Profile

The naming convention is CubeName_ScenarioType.

Clicking on either choice will create the Cube Root Workflow Profile Name. For the purposes of this post, only Sample_Forecast will be used.

It’s easy to identify in the Workflow Profile editor hierarchy as it’s at the very tippy top and has a cube icon to the left of the name:

Default Workflow Profile

Once the Cube Root Workflow Profile is created, the Default Workflow Profile Sample_Forecast_Default appears automatically.

A Default Workflow Profile connects the Cube’s Entities and Workflow itself. All Entities are by default assigned to the Workflow – note that the Entity Assignment property sheet does not exist in the Default Workflow Profile.

Some of its salient characteristics are:

1. It is named CubeName_WorkflowSuffix_Default.
2. It joins Cube Entities to Workflow.
3. It cannot be deleted.
4. Only Administrators should be able to see it.

As with all Workflow Profiles, the Workflow Child Profiles of Import, Forms, and Adj appear below the Workflow Profile name.

A click on the Import Child Profile (this is just illustrative – don’t actually use the Default Workflow Profile) shows that two Scenario Types are available: Forecast and Plan. These are the Scenario Types that share the Workflow Suffix “Forecast”.

Scenarios with Scenario Types

The Plan Scenario has a Scenario Type of “Forecast”. (Remember what I said about the potential for confusion? Here it is.)

Scenario Types are linked to the Scenario Type property in the Scenario itself. This relationship defines the Scenarios in OnePlace. Whew, again.

All you really have to know is that if a Cube’s Workflow has defined Scenario Types, the Workflow is extended and a Scenario tagged with that Scenario Type is now part of that Workflow; only Scenarios with that Scenario Type will appear in OnePlace.

Whew, again and again.

Workflow Profile

Workflow Profile Types

There are three Workflow Profile Types: Review, Base Input, and Parent Input.

As this post is written by Mr. Planning, I’ll confidently state that Base Input is the overwhelmingly most used type in planning applications although of course Review and Parent Input are used as well; Consolidations applications are far more likely to use all three types As the purview of this post is not All Things Workflow but instead Workflow terminology, only Base Input will be examined.

Workflow Child Profile

We have now almost reached the end of our Workflow taxonomical journey.

Note that by default, the Workflow Child Profiles of Import, Forms, and Adj have been automatically created.

Workflow Child Profile types are tied to the Origin dimension, with a fairly logical grouping of Import with Import, Forms with Forms, and Adj with AdjInput.

That’s it – we are at the bottom of the Worfklow Profile tree with Workflow Profile as the most atomic.

There is one more we-call-it-Workflow-Profile-but-really-it’s-something-else element: Workflow Names.

Workflow Names

Workflow Names are confusingly called “Default Workflow” when a Workflow Child Profile is created:

They are called Workflow Names within a Workflow Child Profile:

Think of Workflow Names as the actions that drive Workflow. Given that the property sheet for a Workflow Child Profile uses “Workflow Names”, it seems most logical to use that term when referring to the many, many, many actions (almost 60) they support. Whew, one last time.

As an example, in the Workflow Child Profile Import, I can use the traditional Import, Validate, Load Workflow Name to load data:

Or I can use Direct and change the way data is loaded into the Cube:

Do we have unanimity? Close to it? We should.

Workflow is the core structure OneStream application data processing. Workflow is sophisticated and powerful. Its potential is great, as is its potential to go sideways if discussed and thought about incorrectly.

To use it correctly, we must mean what we say by using the right terms in the right place.

Thus:

1. Cube Root Workflow Profiles are the topmost level of the Workflow hierarchy. They are tied to Workflow Types. Scenarios that have a matching Scenario Type are visible in OnePlace.
2. The Default Workflow Profile is automatically generated when a Cube Root Workflow Profile is created. It bridges Cube Entities and Workflow. Do not use it.
3. Below the main Cube Root Workflow Profile parent, Workflow Profiles join data, metadata, and users.
4. Workflow Child Profiles are where users interact with Workflow be it data loads, forms, or adjustments via Workflow Name action types.

That’s it.

Be seeing you.