v8.0+ Workspaces

[miked]

Hi All,

Does anyone have any good advice on what Workspaces should be created in the application dashboards screen beyond Default?  In reading the guide, workspaces seem to have a lot of focus on separating development activities or perhaps for partner place solutions(?).  I am struggling a bit to understand at what level to offer a different workspace.  We have been toying with the idea of having a separate workspace for Actuals and Planning but as 90% of our dashboards live in Planning, not 100% sure this is the best use of this split.

Any practical advice on the kind of workspaces that people are setting up that adds value?  I want to make sure we are using them in their best manner.

Thx,

Mike

[Henning · Accepted solution]

Hi, the bigger picture is the building software on software part. This is to enable the community (partners and customers) to create their own solutions based on the OneStream platform. As Mike G pointed out, one important element of that is to isolate each component in a different Workspace. On WAVE in Orlando 2023, this was laid out by the developers. Dynamic Dashboards are also a part of that push.

For the community that means - IMHO - that one should start structuring one's Workspaces in exactly that way. Think about how you can leverage that new functionality going forward. How does this help you implement faster and leverage what you build better with less effort? What solutions / modules do you think would meet most market demand? How can those be set up to be sold as a package, or individual solutions? Maybe something "simple" such as an advanced metadata builder? Or a solution in anticipation of new regulations such as Pillar Two (Global Minimum Tax)? IFRS 16 is a role model example for that in my view where Workspaces are extremely valuable, though plenty of solutions exist in OneStream for that one already. Nevertheless, I do see a lot of value also in "small" solutions, not everything needs to address bigger challenges customers face such as ESG, Pillar Two, IFRS 16, etc. 

I do recommend considering attending WAVE 2024 as I presume that the focus will be on that overarching theme there. (Wave North America - OneStream Software)

As for the rules, I think I expressed myself a bit ambiguously. I meant I would add each rule to the Workspace it is used for. Only for overarching (e.g.) solution helpers that I re-use throughout different workspaces, I would create a dedicated workspace for that. Note that Finance Rules are not included in Workspaces (as of today).

With regards to the Default Workspace, this is mainly there to hold legacy dashboards (I.e. before Workspaces were introduced). I recommend to create all new solutions in a dedicated Workspace and not using Default anymore. That is at least how I do it.

In terms of Cube Views and reporting parameters that do not per se belong to a "solution" but may be more functionally oriented, one might consider splitting those up by reporting process (consolidation, planning, etc). Or a dedicated "Reporting" Workspace could also be used. I have not made up my mind on that one yet. But I would personally not use the Cube Views outside of Workspaces anymore, as this is where the Cube Views are stored pre-Workspaces. Going forward, Workspaces should be regarded as the central point for building those items, and that includes Data Management items as well. This is similar to the Default Workspace, which holds the pre-Workspace dashboards.

[Henning]

Hi Mike, 

I tend to see Workspaces to be split by solution. I did not think of splitting it by closing process as various solutions may be used by all / multiple processes. Basically building software on software.

Workspaces are meant to enable you to build solutions in OneStream that are easily portable. So I would build my IC matching solution in a workspace, my allocation solution in another one, advanced journals dashboard next, dynamic cash flow next, etc. etc. This way you have a clear structure in the application as well as enables you to re-use those "modules" for the next projects without having to disentangle them.

Maybe a central repository workspace for all of your parameters you need throughout your other solutions in addition to the aforementioned Workspaces. You could do the same with rules, though I still prefer to have them in the same Workspace.

This is how I tend to see it at the moment but things always evolve and I am happy to see how other people use it!

[MarcusH]

I am still trying to understand the full implications of Workspaces in Dashboards as well. I think it is primarily a method for easily migrating a dashboard from one application/environment to another. The ability to add files and dependencies means that everything a dashboard needs can be bundled together without needing to check that you have all the related Dashboard type Business Rules.

However, I agree with Henning, I prefer to keep all the Rules in the same place. The search facility in Rules is not great and now you have Rules in Dashboards which are not visible at all from Rules.

My current thinking (and I am very happy for others to tell me there is a better way) is to create workspaces loosely based on development streams e.g. Consolidation, Planning, ESG. Keep the Business Rules in the Business Rules workspace. Then use XFProject to specify the elements needed for a Consolidation update or a Planning update. This will allow related Business Rules to be specified and has the option to Replace rather than Merge certain elements (Dashboards being one of them). XFProject is also new to me but it looks really useful for migrating applications. More info here

[MikeG]

Workspaces isolate the artifacts/components for that Workspace.  Notably if you have a Label component and you call it lbl_Blank so as to insert a spacer in a Dashboard, that component can only exist once in the application.  With Workspaces, that label component is isolated to that Workspace, and a component of exact name can exist in a different Workspace, in the same application.

Workspaces offer the ability to have isolated solutions with distinct uses of the artifacts in that Workspace without impacting other dashboards.

i.e. a common naming convention for the primary dashboard is 0_Main.  With Workspaces, each primary dashboard can have that name.  Probably not the best example but you get the point.  As you install and bring in Partner Place or Solution Exchange, and MarketPlace solutions it'll make sense.  OS has been getting by with MarketPlace suffixes such as lbl_Blank_TLP, lbl_Blank_SAR, lbl_Blank_RPTA so as to not step on other solutions artifacts.  

Workspaces solve that.

[miked]

Thx Mike.  Understood.  In light of the unique name issue in past versions, we also adopted the 3 letter suffix to every object in our Dashboard Maintenance Units so our standard already accounts for this.  We are just trying to figure out the bigger picture of what Workspace strategy to use to come up with the best recipe.

[Henning · Accepted solution]

Hi, the bigger picture is the building software on software part. This is to enable the community (partners and customers) to create their own solutions based on the OneStream platform. As Mike G pointed out, one important element of that is to isolate each component in a different Workspace. On WAVE in Orlando 2023, this was laid out by the developers. Dynamic Dashboards are also a part of that push.

For the community that means - IMHO - that one should start structuring one's Workspaces in exactly that way. Think about how you can leverage that new functionality going forward. How does this help you implement faster and leverage what you build better with less effort? What solutions / modules do you think would meet most market demand? How can those be set up to be sold as a package, or individual solutions? Maybe something "simple" such as an advanced metadata builder? Or a solution in anticipation of new regulations such as Pillar Two (Global Minimum Tax)? IFRS 16 is a role model example for that in my view where Workspaces are extremely valuable, though plenty of solutions exist in OneStream for that one already. Nevertheless, I do see a lot of value also in "small" solutions, not everything needs to address bigger challenges customers face such as ESG, Pillar Two, IFRS 16, etc. 

I do recommend considering attending WAVE 2024 as I presume that the focus will be on that overarching theme there. (Wave North America - OneStream Software)

As for the rules, I think I expressed myself a bit ambiguously. I meant I would add each rule to the Workspace it is used for. Only for overarching (e.g.) solution helpers that I re-use throughout different workspaces, I would create a dedicated workspace for that. Note that Finance Rules are not included in Workspaces (as of today).

With regards to the Default Workspace, this is mainly there to hold legacy dashboards (I.e. before Workspaces were introduced). I recommend to create all new solutions in a dedicated Workspace and not using Default anymore. That is at least how I do it.

In terms of Cube Views and reporting parameters that do not per se belong to a "solution" but may be more functionally oriented, one might consider splitting those up by reporting process (consolidation, planning, etc). Or a dedicated "Reporting" Workspace could also be used. I have not made up my mind on that one yet. But I would personally not use the Cube Views outside of Workspaces anymore, as this is where the Cube Views are stored pre-Workspaces. Going forward, Workspaces should be regarded as the central point for building those items, and that includes Data Management items as well. This is similar to the Default Workspace, which holds the pre-Workspace dashboards.

[miked]

Thx Henning.  This is very helpful.  I was going to ask if the default workspace location for cubeviews / dashboards held any value beyond being where the pre-workspace artifacts go but you have answered that...and I will go with that as we kick off into v8.  When you mention rules being added to each workspace, we haven't done too much exploring of Assemblies yet.  Are you talking about Assemblies above or are you just talking about old-school dashboard extenders that we uniquely assign to each dashboard maintenance unit?  We always just have a DE rule (with open and change logic) assigned to each maintenance unit...but I suspect the Assemblies are going to replace or create another for how to handle that setup.  The DE rules cannot live within a maintenance unit without being written in the Assembly file right?

[Henning · Accepted solution]

Yes, sorry for not being clear, I am talking about Assemblies. This is where the rules are stored in a Workspace. Just start small, add your rule(s), split them up and sort them using the Assembly folders and reference them like you are used to from when it was in Business Rules. I.e. you created your own helper functions pre-Workspaces and called then (within or across rules), now you can use assemblies to structure this properly instead of doing this in Business Rules.