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:
Division1
|__ 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:
Company1:
Division1
|__ Finance Dept1
Company2:
Division1
|__ Finance Dept1
etc.
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
