why did 1Stream design their workflow to start from / associated with a cube?


Acceptance Criteria: Definition of fixed, expected behaviour

I created this enhancement request with 1Stream - do you agree with me ?  Do you have any suggestions to improve 1Stream design?

Presently, we have to create workflows under OnePlace > under cubes. That does not make sense as a workflow can update different cubes and report from different cubes.
Why not remove this Workflow hierarchy under Cubes?  Instead,  give us a new Workflow explorer- where we can customize our own folders to contain Workflows. For example, one folder for Planning WF, one for Budgeting.


You could still have workflows for scenario types. You can extend the workflow for different scenario types by adding suffixes on cube properties.


This will let you create new cube root workflow profiles.


Let's say that I want to create a sophisticated folder structure that is not related to Scenarios.

For example, I want the following:
Dept 1 Finance team workflow.

Dept 2 Accounting team workflows.
The existing 1S design is inferior to my design.

Contributor II

What tasks do you want those Workflows to manage?


Normally speaking, Workflows govern the collection, validation and reporting of data entered into the Cube, hence it's logical they are built with association to the Cube and Scenario Types within.

We all know how workflow works, that's why it is illogical to "built with association to the Cube and Scenario Types ".
A workflow can update and run reports from ANY cubes and scenarios. So why not let us build workflows using a Workflow explorer/ tree of any custom design?

Contributor II

In order to sell this enhancement request to the Product team, I feel there needs to be more clarification on what you are looking for.  If I understand you correctly, you could currently do what I think you want to do.  Create Workflows with no regard to Scenarios.  There will always be an association with Workflow to a Cube.  That's because the Data Sources and Transformation Rules need to know what Cube Dimension are being used and identify the Dimension Members to validate against from 1 specific Cube.  Of course, this is assuming data records are being loaded to a Cube through Import, Validate, Load via Stage.  If you had multiple Cubes and are only using 1 Cube Root Workflow Profile, you could set up Workflow where it isn't by Scenario Type.  If I'm understanding you correctly, maybe you are referring to something like this?


Finance and Accounting Workflows would have separate Workflows that can load to any Scenario and Scenario Type ( assuming they have access to them ).  Only 1 Cube would be setup as Top Level Cube for Workflow and NO suffixes defined by Scenario Type.  Data Source and Transformation Rules would be assigned to the Top Level Cube for data loading.  Data Source and Transformation Rules can be unique by Scenario Type.  This could work for a single Cube design, which should only be used in rare occasions or Linked Cube design.  In Exclusive Cube designs, each Cube would require its own Workflow hierarchy so each Cube would be set up as Top Level Cube for data loading.  That means Data Sources and Transformation Rules for Imports that are specific to its own Cube.  In addition, adding another level of security to secure who can see/access which Cube Root Workflow Profile structure.  However, it could be set up the same way as in this screenshot.  If this screenshot is accurately depicting what you are referring to, there are pros and cons to this type of implementation.  Also, the Workflow controls all the data loading, clearing, and locking by Workflow Data Unit which includes Cube.  So Workflow and Cube are closely aligned.  This really goes back to LeeBown question on what is your process and what tasks do you want your Workflows to manage.  

I challenged 1Stream's consultants and they say they will research this.
I would like to mention that your statement is correctly, but it just proves that WF is NOT dependant on cubes and dimensionality.  Its components, such as dashboards and transformation rules are, but WF is not dependant on any cubes.
Again, your statement is correct:
 the Data Sources and Transformation Rules need to know what Cube Dimension are being used and identify the Dimension Members to validate against from 1 specific Cube. "
But I disagree with your other statements:

"There will always be an association with Workflow to a Cube. "
So Workflow and Cube are closely aligned.  

An example of a worflow explorer:

   |__ Finance Dept

                                |__ WF 1 that may update and report from different cubes such as Budget and Planning
                                |_  WF2 that may update and report from different cubes
|__ Accounting Dept
                                |_  WF3 that may update and report from different consolidation cubes
                               |__ WF4 that may update and report from different cubes such as Budget and Planning


Another way to look at it - I believe that Workflow should be people centric, not cube centric - which is the existing design.
In a large company like Walmart, they have people needing different workflows, so WF explorer may go to deeper levels:


   |__ Finance Dept1


   |__ Finance Dept1

I told 1Stream consultants that their present design that locks WF to cubes confused the heck out of me.  Workflow should be steps that a user will take. Not what cubes are updated - which users don't really understand nor care


 TonyToniTone and LeeBrown, 

I'm sure you are more knowledgeable about 1S than I. So while I have your attention, Can I ask a simple question?
How do you handle a sale of a division in your company to other corporations?

For example:

 We have a Division1 selling widgets. It is under a consolidation roll-up for external reporting purposes. After we sold it, we want to stop tracking its history of transactions, so we create another member in Entity dimension called Division1_sold, put it under a different 2nd roll-up in Entity dimension.  We need it to track and wrap up any costs/ revenue pertaining to Division1 that is no longer ours, and so we don't want to report nor consolidate it under the first roll-up.
Is there a more elegant way to solve this problem?  I see that OneStream allows us to set up for each member (such as Division1) that has  a date when 100% consolidation begins and ends .
Please do not answer my  question here is this thread. I'll create another thread to give you more credit and mark your replies as the "Solution".

Contributor II

Now I understand.  Much clearer to me.  Thanks for the further clarification.  Definitely could be debates over design that can help this situation but your enhancement request is fair enough to discuss an option for a possible people centric selection for Workflow.