Can constraints Slow Things Down in OneStream?
Constraints in OneStream are filters applied to metadata dimensions such as Flow, Accounts, UD1, or specific cash flow lines to narrow the scope of calculations, data retrieval, or Cube View rendering. They’re powerful tools, but when applied too broadly or dynamically, can they degrade performance? Larger evaluation footprint A Flow or Account constraint forces OneStream to check every intersection in that dimension. In dense cubes, this can mean millions of evaluations. 1. Dynamic filters are expensive. Static lists (e.g., A#1000, A#2000, Flow#Operating) resolve quickly. Dynamic logic FilterDim, Boolean conditions, or formula driven sets require runtime computation. Why? 2. Stacked or nested constraints multiply the cost. Does layering constraints across Flows, Accounts, and UDs in OneStream force the system to resolve each filter before executing calculations? 3. Reduced parallelism. When constraints slice across cash flow lines or UD dimensions, the engine can’t fully parallelize tasks. Does more constraint mean fewer threads working freely? Do you agree? Why? Cheers
UD or attribute to flag past restatements (Budget pot swaps)
Hello, we are about to start our work on next year budget and we already know that, following a recent restructuration, there will be a lot of pot swaps between departments (e.g. Licence costs used to sit in the department using the software but will now all sit under IT). Some of the them will be just moving a cost center and its history from one department to the next so that will be easy. Our issue is when we do a "pot swap" that moves part of a cost center. In this case we will have a disconnect when we compare actual and forecast unless we restate actual (i.e. also move the cost in actual). My question is on how best to tag/flag the "pot swap" in the actual data so that in reporting we can do like of like comparison (i.e. with past data restated) but also keep the original data. I have 2 potentials solutions: Flag the restatement using an UD: do the restatement of past periods under a specific UD so that we have the ability to see past periods with or without pot swap adjustments Use attributes: I think attributes would work but we have not used attributes in the past so not sure whether it is the best way Does anyone have the same issue and came up with an alternative solution? or has a view on the above options? Many thanks!Create Scenario Member from Rule
Dear Community Members, Found several great posts about creating account members from a rule. I am trying to clone a scenario member (Forecast with Range defined). I have to admit that i am running into a knowledge gap when it comes to how to create some of the properties. I am reading the properties of my source scenario and naively thought i can just use SetStoredValue with the property of the source scenario. Got stuck at InputFrequency. Any pointers to documentation, Golfstream, Community posts, or samples would be greatly appreciated.Local language (Spanish [Mexico]) persists in DimLibrary after removing es-MX frm SysConfig
Dear Community Members, Due to my error in the initial definition of culture codes I ended up with two es-MX local language options in the dim library. I removed the es-MX culture code. One of the two options went away in the DimLibrary, but the second one persists. Then i removed all descriptions from the MemberDescription table where CultureCode = es-MX. Still the DimLibrary shows Spanish AND even more surprising shows the Spanish descriptions. Which leads me to believe that those descriptions are cached somewhere? Any tips? My ultimate goal is to have es-MX culture code and local descriptions. But only one Spanish in the DimLibrary. SystemConfig (this is a locally hosted client) only has en-US defined MemberDescription Table has only English but DimLibrary still has Spanish descriptions but only where defined before. Other members that never had a local translation do not show Spanish (Mexico), see Scenario Actual below. Thanks in advance
