Calculation definitions are not executing in the expected sequence.
Hi Community, I have the following calculations in my workflow profile, but the processes Process_plp and Copy_plp_to_pln run at the same time and not in order. What do I need to do to make them run sequentially? My OneStream version is 8.5.1.
Workflow channels with scenario copies
Hi All, In our multi year planning process, most entities need to upload four sets of fixed costs (all loaded by the same team, but sent to that entity's finance team by different functional teams), in addition to all the driver-based costs we're calculating (mostly based on form inputs). For the four sets of fixed costs, we have four import profiles under the same parent workflow. The entities import their files and then run a DM sequence from a dashboard to run the validate/load for a range of years they can select. When they run this sequence, all import profiles (under the same parent) that have been imported are validated and loaded. We had not set up workflow channels on the different loads, and everything was working as expected. The different import profiles will use some of the same accounts, but different sets of cost centers. We did not see any collision of data when the same accounts were loaded, and if a balance that had previously been loaded in one import was removed from the import template and reimported, the data in that account would be cleared from the cube (even if that account was only used by one of the four imports) after the next validate/load. Now that we have started to copy cube data from one completed scenario (CY) to another blank scenario (CY_v2), so that some changes can be made to CY_v2, we were running into issues with our fixed cost loads in CY_v2 (balances not clearing, other values being overwritten). This makes sense, and we had not considered loading the fixed costs to copied scenarios. We would like to be able to only load one of the four imports (if say the G&A load is the only one with changes) in the CY_v2 scenario. We were hoping that workflow channels on the imports would solve the issue in the copied-to scenarios, but after completing that set up (changing accounts to nodatalock, setting up different data source members for each of the four imports, creating the channels, and applying the channels to the data source members), we are still seeing balances "stuck" in CY_v2 when previously loaded balances to a unique account are removed from the latest upload for one of the imports. We had also gone back and reloaded the "source" scenario with the channels applied, before copying the data and trying to load only a single template to CY_v2. Is there a way to use workflow channels so that all data loaded through that channel is cleared and replaced when a new import is loaded to a data source member where the channel is applied, or will accounts no longer in the latest import be left un-cleared? The documentation on the level 2 and level 3 data units seems to indicate that those accounts will not be cleared, but that does not match the behavior we see in the original loads of multiple sibling import profiles (described and bolded in my second paragraph). It also doesn't seem to match how a typical, iterative planning process would work. Any feedback would be appreciated. Thanks, James
Error when processing of uploaded Excel file
Hi all, Could you please advise how to find error in Excel file which we try to load in OneStream on Import step of workflow. When I click Process button after uploading of file, I see the below message: Invalid URI: The hostname could not be parsed. Unable to execute Business Rule 'ADU_SolutionHelper'. A malformed URI was found in the document. Please provide a OpenSettings.RelationshipErrorRewriter to handle these errors while opening a package.Workflow Leading Practices - Input Data to Parent Entities
Please share your Workflow leading practices to input data to Parent Entities. Thank you. In addition, please help us with three initial questions below: 0. Workflow: Parent Input – Forms/O#AdjInput - Is this Workflow the leading option to input data to Parent Entities? -- We prefer not to use Forms/O#Forms by creating alternative Base E#/A# Members as they are massive. 0. If Forms/O#AdjInput is the leading option: 1. Account Dim: Member Properties | Vary By Scenario Type And Time | Adjustment Type -- How to massively set A#'s 'Adjustment Type' to 'Data Entry' from the default 'Journals'? -- Can we still use Workflow 'Journals' as they are tied to O#AdjInput as the default? Loading Form Data 2. Form Input Template: Format – CSV v Excel -- CSV v Excel: which template format is better and why? -- CSV Template: please share a copy here per OS Support. -- I couldn't find a Form CSV template in Community, Solution Exchange or Design Guide. Thank you, SMEs.
"Cannot execute step because the prior workflow step is not completed"
We have Workflow A, and Workflow B. We get an error when the loadCube step in workflow B, when Workflow A is in Validation step. The error we get is "Cannot execute step because the prior workflow step is not completed. . (WP#WorkflowA.Import:S#Actual:T#2022M1)" The name the actual workflow has been changed to protect the innocent. Our question is: what is causing this issue and how do we fix it? It's not clear in the documentation what exactly triggers this error message. The parameters passed back imply that one cannot load to the same scenario and time if another workflow to that scenario and time is still open. WorkflowA and WorkflowB are loading to the same scenario and time, but to different accounts.Workflow Profile Hierarchies: Security Model | Application Security Roles v Workflow Security
Please share your practical advice to secure Workflow Profile Hierarchies per the two requirements below. Thank you. A. Workflow Profile Hierarchies: Admin v Builder/Business 0. 'Cube Root Workflow Profiles' | Admin and Business | Top Level Cube_suffix 1. 'Default/Child Workflow Profile Types' | Admin/Business 'Cube Root Workflow Profiles' 2. Admin 'Parent/Child Workflow Profile Types' | Admin/Business 'Cube Root Workflow Profiles' 3. Business 'Parent/Child Workflow Profile Types' | Business 'Cube Root Workflow Profiles B. Two Workflow Requirements: Admin v Builder/Business 1. Builder not allowed to see/create/edit: - Admin 'Cube Root Workflow Profiles' - 'Default/Child' and Admin 'Parent/Child Workflow Profile Types' | Admin 'Cube Root Workflow Profiles' - 'Default/Child Workflow Profile Types' | Business 'Cube Root Workflow Profiles' - Admin 'Parent/Child Workflow Profile Types' | Business 'Cube Root Workflow Profiles' 2. Admin/Builder allowed to see/create/edit: - Business 'Cube Root Workflow Profiles' -- Business 'Parent Workflow Profile Types': Review, Base Input, Parent Input -- Business 'Child Workflow Profile Types': Import, Forms, Journals C. Security Model: Application Security Roles + Workflow Security | Admin v Builder/Business 0. Security Groups: 'Admin Roles and Builder Roles' and Child Groups = 'Admin Roles' + 'Builder Roles' 1. Application Security Roles | Manage Workflow Profiles = 'Admin Roles and Builder Roles' 2. Workflow Security = 'Admin Roles' = Admin/Business 'Default Workflow Profile Types' 3.1. Workflow Security = 'Admin Roles' = Admin 'Cube Root Workflow Profiles' 3.2. Workflow Security = 'Admin Roles' = Admin 'Parent Workflow Profile Types' 4.1. Workflow Security = 'Builder Roles' = Business 'Cube Root Workflow Profiles' 4.2 Workflow Security = 'Builder Roles' = Business 'Parent Workflow Profile Types' D. Security Model Results: Admin v Builder/Business - 1 + 2 + 3 + 4 = Workflow Requirement 1 = Fail - 1 + 2 + 3 + 4 = Workflow Requirement 2 = Succeed Thank you, SMEs.Extensibility Series: An Overview of Extensibility in OneStream
What is Extensibility? The concept of Extensibility in OneStream is the capability to incorporate multiple use cases and future growth with a single foundation. I like to relate this to a dinner table that can expand and add additional table leaves while maintaining the same integrity. The OneStream platform, in tandem with Workflow and Extensible Dimensionality expands on this concept by providing users with multiple ways to extend their platform footprint. When designing an application or planning for expansion to the existing footprint, these concepts are crucial to understand and apply correctly. Extensibility in OneStream is a broad topic and can mean something different to each person in the community so I would like to break our language on this topic down further into the following categories: Horizontal Extensibility Vertical Extensibility Workflow Extensibility Platform Extensibility Horizontal or Scenario extensibility relates to the ability to extend and use different levels of a hierarchy for different business purposes. It also provides the ability to target when and where dimensions need to be included in the data model. Have you ever wanted to input data at a parent level? Through horizontal extensibility, that parent can become a base for input in a different scenario by using the scenario type settings and properly applying Cube Dimension Assignments. What if you have highly detailed metadata that only applies to a specific use case? Horizontal extensibility can help limit the potential intersections that aren’t valid for all the other use cases by assigning it only where it makes sense. Vertical or Entity/Cube extensibility relates to the ability to include/exclude detail at different levels up the entity hierarchy. The Data Unit is a key concept to understand in OneStream and it is important to properly manage its size to allow for optimal performance while accounting for future growth. Vertical extensibility also relates to varying dimensionality across business units. When you report consolidated financials, do you need to see the lowest level of department detail? Each individual product? Every project? The most granular GL accounts? If the answer is no to any of these, vertical extensibility can help. Lower-level entities can still report at a detailed level, but the data can be collapsed to a summary level to facilitate the reporting and increase performance. Does your organization have Business Units with very different operations? Perhaps vertical extensibility can provide the flexibility you need to vary the dimensionality at a detailed level but consolidate to a common summary level. Workflow extensibility relates to the ability to vary the input steps & methods within each process flow. Workflow steps and settings can be adjusted on each scenario type or can be combined if multiple processes follow the same responsibility hierarchy. Workflow extensibility can be configured on each parent cube to tailor the software interface to match the process needs. Is your Actual data collection process more import driven and the Planning process more forms, calculations, and dashboard driven? Workflow extensibility can help split these processes and make them easier to manage from an administration standpoint. Are some data collections imported in a centralized fashion while others have their responsibility distributed to more end users? Entities can only be assigned once in a Workflow hierarchy so to vary the entity signoff responsibilities, Workflow extensibility should be utilized to allow for differing entity assignments. Platform extensibility relates to the ability to vary where data is stored and how it is utilized within the platform. It also includes the ability to have multiple applications within one environment that can talk to each other. OneStream has the unique ability to consume, utilize, and report on data regardless of if it is stored in cubes, relational tables, or even externally. The capabilities in this category are expanding rapidly and should be considered during all solution design activities. Do you plan at a named personnel level? By each individual capital project? It’s important to determine what is necessary in the cube for consolidated reporting versus what can live outside the cube to be reported on more at a base entity level. Through platform extensibility, we can combine cube data with relational data to achieve the optimal balance between performance and reporting needs. Is the process you are designing more operationally driven and your data dimensions more transient in nature? Perhaps none of a specific data set needs to live in a cube, or even OneStream at all. Platform extensibility allows us to utilize entirely relational data, web content, and even external data sets. How should one think about Extensibility? Extensibility is foundational to OneStream. It should be thought of as a tool as essential as the level. Without it, you can probably get the job done and, on the surface, it might look okay as well. But over time, you are likely to discover structural integrity issues. It is probable that what you built may no longer be able to do everything you need it to. We use extensibility to right-size data units. We use extensibility to input at the right level. We use extensibility to fit the business process. We use extensibility to set the foundation for the future. I’ve heard people talk about extensibility in that you are “locked in” to the choices you make now. While there is some truth in that, it should not be thought about as a box, but a key to the future. Applying extensibility opens the door to so many more options in the future. Design the process and use extensibility as the tool to bring it all together. As mentioned in the Guiding Principles article, the importance of designing the process cannot be stressed enough. Don’t look for a tool, look for a problem and use the tools provided. Be forward thinking during design and ask questions to all stakeholders to make sure future functionality is accommodated for. Be sure to understand how the business operates and what is on the roadmap so that the proper foundation can be built. Recommendations I will begin with a disclaimer, there is not a single be-all, end-all way to implement extensibility in OneStream. I have seen applications with no extensibility and ones with too much extensibility. While there is a middle ground that should be found, the applications without extensibility are those that much more commonly have issues. A lack of vertical and platform extensibility tends to lead to performance issues. A lack of horizontal and Workflow extensibility tends to lead to flexibility issues. The applications with too much extensibility less commonly run into performance or flexibility issues, but they do have a higher maintenance burden. This is why, as architects, it is our job to balance performance, usability, and maintenance when thinking about these four types of extensibility. It is our recommendation that extensibility be considered in every single design and that it should be implemented nearly every time. To not use extensibility should be an exception, not the norm. During a solution design, I like to fill out a matrix like the one below to visualize what detail needs to be included where. With this, you can start to shape the Scenario Types, cubes, dimensions, and any platform extensibility. When looking for extensibility configuration examples, look no further than our CPM Blueprint application. This application has example configurations using our leading practices. Looking at UD1 as an example, one can see our common configuration of a “MainUD1” dimension parent to summarize the BU and Cost Center details into a common dimension. This is a concept we apply to all user defined dimensions to facilitate both vertical and horizontal extensibility. To facilitate vertical extensibility, dimensional detail that is not needed in a parent cube can be collapsed by assigning MainUD1. The dimensional detail is then extended from “TotUD1” to expand into the necessary levels of detail for each data collection and reporting need. This allows both “None” and “Top” to be active at all levels in the dimensional hierarchy. Another example of extensibility on display in the CPM Blueprint application is in the cube configuration. Focusing on the financial reporting structure in this application, it follows our recommendation for a base-summary cube relationship between Business Unit and total company reporting. I commonly apply this configuration even if there is only a single child cube and a single parent cube because it opens the door to so many more options in the future: More flexibility to expand child cubes horizontally and plug in different dimensionalities Greater ability to collapse the data unit if its size becomes an issue Further future-proofing as it allows for more platform expansion with the same foundation Finally, this application also has Workflow extensibility on display. On the cube settings, you can see the connection between top level and base cubes. You can also see the Workflow suffixing applied in the CPM Blueprint application. In this example, the Actual Scenario Type has a different process flow and responsibility hierarchy from other data collections, so it has been given its own suffix of “ACT.” Budget and Forecast follow the same process flow and responsibility hierarchy so therefore share a Workflow suffix of “BUDFCST.” This allows each process to have its own configuration and entity assignment. Conclusion Extensibility in OneStream cannot be overlooked. During a solution design, each of the four types of extensibility should be weighed and discussed to see which tool is right for the job: Horizontal Extensibility Vertical Extensibility Workflow Extensibility Platform Extensibility If you conclude that extensibility is not right for you, be absolutely sure. If the choice was up to me, the benefits of future flexibility and performance reliability greatly outweigh the potential need for additional administration overhead and end user training that come with extensibility.
Workflow Import - Clearing cube data in v9
Hello, we recently upgraded to v9 and noticed that we can no longer clear WF imported cube data using the "Clear" option through the workflow import (snip below). Prior to the upgrade, we could clear the stage data, then run import/validate/load to clear the data that was imported to the cube. Now, this option only clears the data from stage and in order to clear the data loaded to the cube, we have to use a data management step. In our case, this is now difficult because the data loaded may be specific to workflow channels and also use multiple dimension criteria and not just Entity (used by DM step). Is anyone else having this issue? Are there any other methods to removing the imported data via csv file from the cube other than a DM step? If we try to run the old process in v9. Clear, then Retransform, Load to clear cube data. This error appears.Get dependent entities on a review level workflow
Hi All, We have a parameter attached in the entity POV of all our cube views, and it works perfectly on base level. However, not in the review level workflow. Is there a way to include dependent entities in a review-level workflow via XFBR String? The entities in the review level are dependent, coming from the assigned entities in base level workflows underneath it. I have tried using objList = BRApi.Workflow.Metadata.GetDependentProfileEntities(si, profileKey) with no luck. Perhaps I am missing something. Bound list has been tested as well, and attaching the parameter in the POV of a cube view, only works in the base level workflows as well. When the workflow is a review, it will show a full list of entities that we do not want. Is there a way through the XFBR string and parameter in the member dialog? Appreciate all suggestions.
