07-26-2022 04:59 PM - last edited 2 weeks ago by JackLacava
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.
07-26-2022 05:16 PM
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.
07-26-2022 05:33 PM
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.
07-27-2022 06:29 AM
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.
07-27-2022 09:24 AM
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?
07-29-2022 01:34 PM - edited 07-29-2022 01:43 PM
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.
07-29-2022 01:48 PM
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
07-29-2022 01:51 PM
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
07-29-2022 01:55 PM
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
07-29-2022 02:20 PM
TonyToniTone and LeeBrown,
07-29-2022 02:39 PM
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.