Best Practice to Clear Stage Data Globally and Cube Data for Selected Entities
Hi Team, I’m looking for guidance on the best approach to clear data in OneStream. My requirement is twofold: Clear all data from the Stage area For a selected set of entities, clear both Stage and Cube data I’m particularly interested in understanding the most efficient and recommended way to handle this, while ensuring data integrity and minimizing any unintended impact. Specifically, I would appreciate insights on: Recommended methods to clear Stage data globally (e.g., via Data Management steps, Business Rules, or utilities) The best approach to selectively clear Cube data for specific entities Any considerations around workflow locks, data unit locking, or audit/history implications Performance best practices and recommended sequence of operations If anyone has implemented a similar requirement, I’d love to hear your approach or any lessons learned. Thanks in advance for your help!
How to "Import" "in parallel" via a "OneStream Connector" to a "Data Warehouse"?
Please share your practical advice to help us meet the new Integration requirements. - I couldn't find a OneStream KB/post nor a good result from free Gemini. - We're using SAAS on v9.0 to move to v10 upon its upcoming release. Thank you folks for sharing your expertise.
Including Journal Entries from Different Origin Member in Account Reconciliation Discovery
Hi Community, I’m working on an Account Reconciliation solution where I need to ensure posted journal entries balances are also included in the Account Reconciliation discovery process. Currently, by design the Discovery process only pulls trial balance information already imported and validated in the Stage. Therefore, I wanted to check if there’s a recommended, or best practice approach, to accomplish this requirement. Any guidance or examples would be greatly appreciated, thanks in advance for your help!Import with Vertical Extensibility or Extensible Dimensions
Hi, I can’t get my data import to work with vertical extensibility, and I’d like to understand how this situation is supposed to be handled. In short, the import validation fails on accounts that are extended for an entity. The entity belongs to a cube that is vertically extended from the primary workflow cube. Detailed situation I have extended dimensions and two cubes that use those dimensions. CubeParent contains a parent entity with dimensions applied. The parent entity resides in the parent entity dimension. CubeChild has dimensions that are extended from the parent’s dimensions. The child entity resides in the child entity dimension. As a result, each cube has its own unique entity dimension containing its respective entity. Additional configuration details: CubeChild has Is Top Level Cube For Workflow set to False. CubeParent is the top-level cube and has the Workflow Profile created from it. The child entity has been added as a child of the parent entity in the parent’s entity dimension (see screenshot). CubeParent has the Cube References tab configured correctly. Data import issue I have configured a data source that reads from a CSV file. The data source successfully loads the CSV into the staging area. However, the transformation step fails. The failure occurs only for the child entity’s extended account, not accounts in the ParentCube account dimension. The transformation rules when created are associated with a cube. If the cube is not that of the workflow profile the transformation rule does not appear in the import configuration step. Question How should data be imported for an entity that exists in a workflow that has different dimensional detail than the cube it belongs to because it is using vertical extensibility?
