Recent Discussions
Problem With DM Sequence Parameter Resolution Order
Good afternoon, I'm encountering an issue and hoping someone could share how they've worked around this in the past. We have a task that runs over a finite number of Entities. Historically the underlying Business Rule was kicked off via DM Step with Entity: E#Top.Base. It's not exactly "Top" but something similar to hopefully capture all relevant Entities to this particular task. The runtime was always a consideration as it also runs for all remaining periods within our current year. In an effort to reduce runtime we introduced a "Unique Entity" parameter. This is defined by a Business Rule that runs and queries a source table to determine only the Entities that this particular task needs to be run on. In practice this has greatly reduced runtime on the task. Runs more than 2x faster. The problem: The source table that populates the list of "unique entities" is also updated within the same Data Management Sequence. Something like: 1) Update source table 2) Run task described above Because both Steps are within the same Sequence, the "Unique Entity" business rule is being executed before #1 Update source table happens. So any changes to the source table versus a previous run could cause an Entity to be missed. I wish the Filter would get resolved when the Step is executed instead of when the Sequence is executed. Hopefully that makes sense to everyone? The only workaround that I'm aware of is to kick off the 2nd Step at the end of the 1st step. This removes a lot of the visibility and, as part of our current process, Step 1 is sometimes executed on its own to preview Stage data before the full Cube posting takes place. I appreciate anyone who can provide guidance on this matter. Thanks, Brandon
Assembly in DM Job
Hi OneStream I am trying to add an XFBR from Assembly using the guide ´, and have tried various ways. I tried Current, and even adding the WSMU, and the whole workspace name as well, but to no luck. The data management and the assembly are both in the same workspace/DMU. I believe I am missing the correct way to add the XFBR. Can you please advise what the correct way is? Appreciate it. Thank you.Entity-Specific Historical FX Rates for Acquisitions — A More Accurate IFRS Translation
Stop Fighting Your Equity Translation — Let HSR Do the Heavy Lifting A 5-minute read for anyone who's ever stared at a CTA movement and whispered: “Where did that come from?” _____________________________________________________________________________ The consolidation problem we all know It’s day 4 of close. Consolidation runs clean. FX looks fine. Then someone opens the equity rollforward. “Why is acquired share capital moving again?” The entity was acquired years ago at a historical acquisition rate, but the system is retranslating equity at current closing FX every month. CTA absorbs the movement. Auditors ask questions. Finance posts manual journals. Everyone loses time. This is the classic Historical Spot Rate (HSR) challenge. The design principle The goal was simple: Freeze selected equity accounts at acquisition FX rates while keeping the standard OneStream Software translation engine intact. No new cube. No custom dimensions. No complicated override framework. Just: metadata tagging, controlled FX logic, and safe fallback behaviour. The HSR pattern Component Design Entity activation Entity.Text5 = "HSR_Entity" Equity tagging Account.Text15 = "HSR_Accounts" Historic rates Stored in dedicated HSR rate technical accounts Translation logic Finance Business Rule Audit trail Dedicated FX movement flow HSR = Historical Spot Rate. The rule only activates when BOTH: The entity is tagged, and The account is tagged. This creates a simple but effective control framework. The historic rate storage design should remain flexible: use technical accounts, use whatever Text property the project governance model agrees on, and confirm all translation account tagging requirements with the Group Reporting Manager before deployment. What does the rule actually do? Check if Entity is HSR_Entity Check if Account is HSR_Accounts Retrieve stored historic rate Calculate FX adjustment Post adjustment to MVMT_TRANS_FX If anything fails → revert to standard FX That last line is important. The design intentionally prioritises: consolidation stability, auditability, and safe fallback behaviour. If metadata is incomplete or a rate is missing, the application simply reverts to standard FX translation logic. No broken consolidations. No blocked close process. Why did this work well in practice? The biggest advantage was operational simplicity. Adding a newly acquired entity became: Load historic rate Apply metadata tags Run consolidation No code changes required. The approach also kept: CTA cleaner, Equity movements are more stable, And audit support is significantly easier. The real challenge: governance The code itself was straightforward. The harder part was operational discipline: Maintaining 1:1 entity-to-rate mapping Controlling metadata tagging Defining fallback expectations Building reconciliation reporting Testing CTA behaviour thoroughly In my experience, most FX translation problems are not technical problems. They are governance problems. Community question I’d be interested to hear how other certified OneStream Software architects and administrators are handling Historical Spot Rate scenarios. Particularly: Are you using metadata-driven activation? How are you storing historic rates? Have you handled HSR entirely through translation override logic? Any alternative designs that further reduce maintenance? How are you handling CTA transparency and audit reporting? Always interested in seeing cleaner or more efficient approaches from the community.
Another user is already logged into the application on this client - Anyone else experiencing this?
Hi OS Community. has anyone encountered this error when logging into OneStream? "Another user is already logged into the application on this client. That user must log out of their external identity provider before you can log in." I ran into this issue today with a user and wanted to see if anyone has experienced the same thing and found a fix. Any help or suggestions would be greatly appreciated. Thank you! Edit: I found a similar post from past [ Unable to Login into OneStream] where it was suggested to log out of the organizational SSO account, but just wondering if there's a permanent fix or root cause of this.
Missing underscore in member names displayed via combo box
Hello! We have a missing underscore in a combo box and I'm not exactly sure why... Here's what shows: Here's how entities are set up: Anyone see this before? Seems related to this one which says it's resolved in 7.1.3 but I'm not seeing that: Underscore in member name not displaying in multiselect listbox | OneStream Community
App Copy and System Parameters
Hello, When we refresh a lower environment from our production environment (app copy), the target environment's System Parameters/Secrets are refreshed from the production System Parameters/Secrets. These secrets contain connection strings to another platform and are environment specific. They must remain static. (Fortunately, I export them before a refresh and then re-import them after.) There must be a better way! Does anyone else have this issue? If so, is exporting/importing the System Parameters the only way to keep System Parameters with their correct environments? Thanks!Workforce Planning | Invalid Column Name
I'm receiving the following error when trying to add additional Register Definitions. During the build, I've added new Register fields as requirements evolve but now am facing this error when running the Update button. Has anyone run into this issue and resolved it? Error executing Workspace Assembly Service class 'Workspace.PLNB1.CustomEventHandler_PLN.WsAssemblyFactory'.Invalid column name 'PayGroup'. Invalid column name 'Location'. Invalid column name 'EmpStatus'. (SQL Error Number -2146232060, 207, 207, 207). User Interface Stack Trace: at OneStream.Client.Api.DashboardsAjaxServiceReference.DashboardsAjaxServiceClient.StartExecuteSelectionChangedServerTaskCompressed(SessionInfo si, Boolean isSystemLevel, Guid primaryDashboardID, Guid embeddedDashboardID, Guid componentID, PageInstanceInfo pageInstanceInfo, XFSelectionChangedServerTaskInfo serverTaskInfo) at OneStream.Client.SharedUI.DashboardWcfHelper.ExecuteSelectionChangedServerTaskAsync(SessionInfo si, Boolean isSystemLevel, Guid primaryDashboardID, Guid embeddedDashboardID, Guid componentID, PageInstanceInfo pageInstanceInfo, XFSelectionChangedServerTaskInfo serverTaskInfo, OnAfterExecuteSelectionChangedServerTaskDelegate onAfterExecuteSelectionChangedServerTask, Object userState)
