Announcement
ABC
Recent Activity
Mastering Dashboard Load Events, Component Actions and Advanced Parameter Handling
For those of us creating Dashboard solutions in OneStream, there are a couple of Services for us to master, that provide us with total control over how Dashboards load, Component actions, refreshes and Parameter Handling, this blog is going to touch upon two of these, namely the Dashboard Service and Component Service, in the Service Factory. Dashboard Service Type Component Service Type The History: A quick history lesson on what we are covering here, before Workspace Assemblies, this functionality already existed (and still does), in a Dashboard Extender Business Rule. Business Rule Types 1) Load Dashboard Function Type 2) Component Selection Changed Function Type We would call each function type using syntax like this this e.g. {YourBusinessRuleName}{YourMethodName}{} The key difference in that the On Load event is called specifically from a Dashboard itself (usually this will be the Top-Level Dashboard). Whilst the Component Selection Changed events are called directly from the Dashboard Component e.g. We can still utilise functionality this way, but this blog will focus on execution via the Dashboard and Component Services, in the Service Factory, of a Workspace. We will also focus on DashboardExtenderArgs, the XFLoadDashboardTaskResult and the XFSelectionChangedTaskResult objects in this blog and convey how powerful they can be for Dashboard Developers. Note: This blog will use C# examples, but you will see the syntax is nearly identical to the VB.Net equivalent. Dashboard Extender Args: Before we jump into the example, I want to talk a little bit about DashboardExtenderArgs, in the context of both Services. One of the things that is most graceful about the Dashboard and Component Services is DashboardExtenderArgs. In the context of these two services, we can use DashboardExtenderArgs in a couple of different ways, in addition to simply using the values passed in directly to our method(s) using args.NameValuePairs, which is a Dictionary<string, string>. In the Dashboard Service, we can retrieve a different Dictionary<string, string> of all the KeyValuePairs from the prior run e.g. the last time the Dashboard was run using args.LoadDashboardTaskInfo.CustomSubstVarsFromPriorRun. We can then use these to set Default values for initial Dashboard invocation (more to come on this later in the Dashboard Service section). Whereas in the Component Service, we can retrieve yet another Dictionary<string, string> of all the KeyValuePairs associated with your dashboard parameters already resolved by using args.SelectionChangedTaskInfo.CustomSubstVarsWithUserSelectedValues. What this means effectively is you no longer need to pass in NameValuePairs when calling a Dashboard Extender rule, in the same way that we do with a Data Set or XFBR rule, for example e.g. {WS}{YourMethodName}{Key1=[|!prm_YourParam1!|], Key2=[|!prm_YourParam2!|]} As you can see below, from our perspective both are dictionaries of KeyValuePairs related to Dashboard Parameters; but the Key we use with this dictionary (to lookup the Value) is the actual parameter name and all resolved parameters appear in this dictionary. That’s the main difference and the reason it is so useful. {WS}{YourMethodName}{} The Dashboard Service: In terms of setup and execution, the Dashboard Service is simple. We use it to set default Parameter values when a Dashboard loads for the first time. This is important if we want to set default values or we are using nested parameters, for example where we have dependencies that must be resolved at initial run time. We typically set this on the Top-Level dashboard, because we only expect it to fire the first time a Dashboard is run (see IF statement below). It is not generally a good idea to set this on an embedded dashboard (not Top Level), so that we do not lose control over Parameter actions. To call the Dashboard Service we need to set Load Dashboard Server Task to Execute Dashboard Extender Business Rule (Once). - ChangeCustomSubstVarsInDashboard We can then use the XFLoadDashboardTaskResult object to ChangeCustomSubstVarsInDashboard e.g. set to True and then set our default NameValuePairs in the ModifiedCustomSubstVars Dictionary. This is a way to ensure Parameters have values that we can control when a Dashboard is run, for the first time. We will see this approach again, later in this blog in the Component Service. The Component Service: As you can see, the Dashboard service is simple, but effective, but the real fun starts when we start to look at what we can do after the initial run using the Component Service. This is the Service that enables us to have full control over what happens within a set of Dashboards, after they have been run for the first time e.g. catching the result from a Dashboard Component Parameter e.g. a Combo Box, to impact the result of another Dashboard Component e.g. a Cube View, etc. So, let’s start by looking at a Dashboard Component itself to understand how we can interact with the Component Service. On every Dashboard Component object there is a configurable Action section e.g. see next image. We can configure all of this with a no-code approach… But if we want to guard against certain conditions, we can extend this functionality by using the Component Service. This is important because we can perform the same functionality from the Component Service for the User Interface Actions and the Navigation Actions. Please note, we cannot replicate Save, POV and Server Task Actions using the Component Service XFSelectionChangedTaskResult object. Now let’s move onto the most powerful of all the objects in the blog, the humble XFSelectionChangedTaskResult object, in terms of what it does and how it can be used for targeted and refined Dashboard / Parameter actions. XFSelectionChangedTaskResult: The XFSelectionChangedTaskResult object is the object returned from this service to the dashboard interface. Please observe most controls are set to False by default. Next, we will deconstruct each of these properties. You’ll notice they come in pairs with a Boolean switch for each and they can be used together and interchangeably. It should also be noted that generally we always set the IsOk property to true when returning this object. To call the Component Service we need to set Selection Changed Server Task to Execute Dashboard Extender Business Rule (General Server). - ShowMessageBox The first properties we will cover here are exclusive to the Component Service and not available directly via a Dashboard Component. This is to return a message to the dashboard; once the task is complete or to return a validation message, etc. We would then set the ShowMessageBox control property to true and pass a string to the Message property e.g. Hello World. The result would look something like this example, where a dialog is returned to the UI with the message displayed - ChangeSelectionChangedUIActionInDashboard Next, probably one of the most powerful attributes of the XFSelectionChangedTaskResult object is the ChangeSelectionChangedUIActionInDashboard properties. This replicates the User Interface Actions we can configure on a Dashboard Component But we can use it here in the Component Service to override what the Component does based on a condition, for example. Let’s say that we want to test that one of the variables passed in as actually populated and if not, we do nothing. So, this ability gives us total control over Dashboard and Parameter actions, once we are in the Component service. That said, it is important to still use the Dashboard Component itself for the original actions to make the solution transparent and readable. Just because we can perform most functions at the code level; doesn’t mean it’s necessarily the best approach from a design and maintenance perspective, for example. Remember to Keep It Simple. - ChangeSelectionChangedNavigationInDashboard Next, we have the Navigation Actions. Here, again we can replicate the same actions inside the Component Service as we can on the Dashboard Component itself. Again, here we have options to guard Navigation Actions, if for example a Parameter Value that is required, has not been resolved by the Dashboard UI itself; we can set the XFSelectionChangedNavigationType to return NoAction, like we did in the example above. The next two attributes we cover are broadly similar and both are related to Parameter Dictionaries, but each has a different use case and are usually accompanied by a Dashboard Action such as a Refresh. Input Value Parameters Over Literal Value Parameters: Parameter examples shown here are largely for Input Parameters e.g. Parameters that use Parameter Type Input Value. These are generally favoured (instead of Literal Value Parameters) because they observe the User’s Session; as opposed to Literal Value Parameters, where the value persists for all users and are therefore not particularly safe to use when we expect > 1 user to interact with our Dashboard and Get / Set Parameter Values. - ChangeCustomSubstVarsInDashboard Typically, the reason why we use the ChangeCustomSubstVarsInDashboard approach is to ensure a parameter and its value reach the target Dashboard being refreshed by this Component Action. So, they provide the ability to manipulate the values assigned to a Dashboard (like example below) or reinforce a targeted set of Parameter passes from a source Component Action to a target refreshed Dashboard (which is sort of the name of the game when it comes to robust Dashboard Development in OneStream). As you can see ModifiedCustomSubstVars is simply a Dictionary<string, string>, where the Key is the full Parameter Name and the Value is the value assigned to that Parameter. Together they form the KeyValuePairs that the Dashboard consumes. - ChangeCustomSubstVarsForLaunchedDashboard The key difference with ChangeCustomSubstVarsForLaunchedDashboard is that here, specifically we are passing a Dictionary<string, string> directly to the Dialog Dashboard that is being opened. This is important because the Dialog usually sits outside the Main Dashboard, often in a separate group and has no concept of these Parameters. An example of how we would set this up via the Dashboard Component is below… … and by calling the Component Service we can pass KeyValuePairs directly to the Dialog. Here we can stipulate this on a parameter-by-parameter basis e.g. like above, but where we set default parameter values or we can simply pass all the resolved parameters to the Dialog using a simple trick like below. Tailor Your Approach: Now that we have deconstructed what each element of the XFSelectionChangedTaskResult object does, how to use it and which Parameter Types work best for this approach. Let’s now look at blending some of these techniques together in a real-life use case. For the purposes of this blog, I have created some very simple components and two parameters to demonstrate how to pass parameter values around correctly through these Actions (a common use case). This is the Workspace and everything underneath used for this demonstration… Blog Workspace example We are using the Dashboard Service, the Component Service and the Service Factory, in our Assembly. In main Dashboard a_A_Blog, we have set the On Load function. We also have some components e.g. We have a Text Box for Inputs... That uses a single Input Value Parameter e.g. prm_YourParamName1. We also have an Open Dialog button (see below), please observe User Interface Actions below. The other important thing to observe here is we set the Dashboard we want to Refresh after the Dialog action here e.g. at the point of Opening the Dialog, instead of attempting this using the Component that closes the Dialog. In the Dialog that we open e.g. a_dlg_A_Blog, we have another Text Box This one uses a different Input Value parameter e.g. prm_YourParam2 And we also have an Execute Save Button. This sits inside the Dialog and will close the Dialog, once complete. Please also observe that for both Component Service calls, we are not passing in any NameValuePairs to either method, since we can get these from DashboardExtenderArgs, as demonstrated earlier in this blog. Now, that we have gone through the Dashboard setup, and before we look at the Code; let us review the simple Dashboard UI. Now let’s look at the code. For the Open Dialog button. We can see that we can get all the Parameters we need from DashboardExtenderArgs. We enable ChangeCustomSubstVarsForLaunchedDashboard (since our button is opening a Dialog) and we set the value of the parameter that is being passed to the Dialog. In real life, this is common to set defaults or pass existing values to be used by Dialog dashboards. So, we open the Dialog using the Button and set the value of the parameter in the Text Box in the Dialog (prm_YourParam2) to be null and guard against the first input parameter being empty e.g. we do nothing when this condition occurs. When the Dialog is open, then we can input a new value in the Text box in the Dialog e.g. against prm_YourParam2 and click the Save button. This triggers our OnExecuteSave method, where we take the value assigned to prm_YourParam2 and update the original prm_YourParam1 value with the new value e.g. UpdatedValue. When we close the Dialog, it invokes the refresh that we had set on the Open Dialog Button User Interface Actions and we can see the updated result when the Dialog is closed and the main Dashboard is refreshed. Now that we know how to control Dashboard Actions and handle parameter passes effectively, we can build more sophisticated Dashboard Solutions with targeted refreshes, guarded actions and parameter handling like a professional.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.
Registration for Tech Talks: Building OneStream from WinApp to Browser is now open!
1 MIN READ Join Eric Hanson, Tom Linton and Matt Kerslake as they explore bringing a OneStream application created through the Windows App and building it out through the browser! Eric will share tips, insights and guiding principles to optimize your OneStream browser experience! Register now! https://www.onestream.com/events/tech-talks-building-onestream-from-winapp-to-browser/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.The New Community Experience Arrives June 8, 2026
3 MIN READ Mark your calendar! The launch date for the new OneStream Community is now set. On Monday, June 8, the OneStream Community will upgrade to a new platform, providing a new experience for all new and existing users. This move will bring new enhancements and an overall better experience to the Community you know and love. Why are we updating the OneStream Community? Our goal is to empower every member of the OneStream Community with A PLATFORM that enhances connection, accelerates learning, and makes engaging with the community easier and more valuable than ever. The OneStream Community team is committed to ensuring our users always have access to the best possible experience. We’re investing in cutting edge AI capabilities, modern design, and smarter tools—all delivered through a trusted, reliable, and secure platform you can depend on. ENHANCED analytics—paired with new customization capabilities—will allow us to tailor experiences to each member’s needs and surface more relevant, meaningful content. By understanding what matters most to our users, we can continuously refine the community, deliver more targeted value, and ensure every member feels supported, informed, and connected. When is this happening? The launch will happen on June 8, 2026. Starting the week prior, on June 1, 2026 @ 12:00am CT, the current community will be set to read only mode. This means the Community will be TEMPORARILY FROZEN from June 1, 2026 to June 5, 2026 and members will be unable to post new content, post new comments, or otherwise create anything new on the Community. Once the upgrade is complete, members will once again be able to post and engage with the community as usual - but on the all-new platform. Keep an eye on the Community blog for notifications of when the launch is complete. Who is impacted by this? Members of the OneStream Community, including Customers, Partners, and OneStream Employees will all experience this launch and enhanced community experience. Customers, Partners, and Employees who do not yet have an account may create one before or after the launch; however, new accounts cannot be created during the read-only period. How do I gain access to the new Community? The new OneStream Community will remain accessible via the “OneStream Community” button in your OneStream Okta app. Additionally, the new OneStream Community will be housed at a new URL, which will remain largely ungated and visible to Prospects and Guests alike. Details coming soon. How do I stay informed? The OneStream Community team will post notifications when the current community enters read only mode, and again when the new Community is live. Subscribe to the OneStream Community blog today to ensure you receive the latest news and updates from the OneStream Community. Frequently Asked Questions Can I still login to the Community? You can login and use the OneStream Community as usual until June 1. From June 1 through June 5, you will be able to login but you will be unable to interact with the Community until the migration is complete. These interactions include posting new content, liking / upvoting posts, posting replies, joining groups, etc. Will I need to create a new OneStream Community account? No, your OneStream Community account will transfer to the new platform, which includes your username, email address, activity (posts, likes, etc.) as well as your appropriate role, such as Customer, Partner, or Employee. Users who do not yet have a OneStream Community account but would like to sign up may do so prior to June 1 or anytime after the launch on June 8. What will not transfer over? Your rank, profile picture, subscriptions and personal settings will not transfer. Formerly earned badges that exist on the new platform will transfer to the new platform, but any badges that do not exist on the new platform will not carry over. Note: Badges will be assigned following the launch of the new experience. You will receive notifications when your badges have been published to your profile. What do I need to do? When the new platform launches June 8th, simply login via Okta as usual. That's it! More Questions? Comments? Let us know your thoughts in the comments below!Tech Talks After Hours: Journal Entry Manager (JEM) Part 2
Go beyond the basics of Journal Entry Manager and join Chris Morelli and Tom Linton dive deep into ERP setup, extract and format options, template configuration, and automation best practices. To receive OnePoints for watching this Tech Talk video, please visit the link below: Journey Entry Manager (JEM) Part 2Close Faster. Build Smarter. Scale with Confidence.
2 MIN READ As OneStream continues to evolve, so does the way you learn, apply, and expand your expertise. Global Education Services (GES) has released a new wave of courses, certifications, technical deep dives, and enablement resources—each designed to help you move faster, make better decisions, and deliver real impact in your organization. Whether you're focused on financial close, reporting, planning, or development, your next step starts here. Explore all learning opportunities in OneStream Community and Navigator. Close Faster and with More Confidence (Finance Teams) Accelerate your close and validate your expertise with targeted certification and reporting training. OneStream Certified Specialist (OCS) – Financial Close exam OCS Financial Close study guide Reports and Dashboards Certification Exam Prep webinar (now free in Navigator) Strengthen your reporting and operational readiness with: OneStream Reporting Tools (free Navigator module) Journal Entry Manager Readiness Toolkit (updated with new video content) Tech Talks: Journal Entry Manager (JEM) Tech Talks: SFTP Data Integration – From WinSCP to SSH.NET Take the next step: Get Certified. Get Recognized. Watch the session Build Better Dashboards and Analyze with Precision (Report Developers & Power Users) Create more flexible, insightful reporting experiences with modern tools and techniques. Working with Dynamic Grids microcourse Tech Talks After Hours: Dynamic Grid Components Tech Talks After Hours: Bringing Data to Life For teams exploring advanced modeling: Line Item Modeling overview video Start building more dynamic and impactful reports in Navigator. Start the course Design Smarter Planning, Workforce, and ESG Solutions Align planning strategies with real-world requirements and expand into emerging areas like ESG. Planning Framework modules (PV910 SV100, PV920 SV100) Workforce Planning with Line Item Modeling For ESG initiatives: ESG Reporting and Planning Readiness Toolkit Using and Managing the ESG Solution (Passport-exclusive module) Empower your planning strategy with guided, practical learning. View course Extend OneStream with Genesis and Custom Development Build scalable, modern solutions with hands-on development training. Genesis Challenge (end-to-end applied learning experience) OneStream Solutions: Using Plug & Play Architecture with Genesis Strengthen core development skills: Building C# Logic – Control Flow, Error Handling, and Methods Tech Talk: C# vs VB.NET Explore advanced architecture and packaging: Genesis Development with the Solution Packaging Kit (SPK) Genesis SPK from Scratch: Part 1 and Part 2 Empower your journey as a OneStream developer. Start the challenge Learn, Explore, and Stay Current Continue building your expertise with structured content and real-world insights. OneStream Press titles: OneStream Fundamentals OneStream Workspaces and Assemblies The OneStream Podcast: Hear directly from OneStream leaders, partners, and experts through recent episodes, including: Partner Spotlight series Solution deep dives CPM Express success stories Author discussions on modern architecture and development Your Learning Journey Starts Here From certification to development, from reporting to ESG, every resource is designed to help you apply what you learn immediately and drive results faster. Engage. Learn. Grow. Explore the latest courses, tools, and insights today in OneStream Community and Navigator.How to Pull Workflow Certify Comment into BR Email
Hello, I'm trying to pull in the certify comment section when a user clicks on the "Set Certification Status" button. We currently are using the Workflow Event Helper to send the email when the certification is set to In-Process or Certified. Dim oEntityList As List(Of WorkflowProfileEntityInfo) = BRApi.Workflow.Metadata.GetProfileEntities(si, oWorkflowInfo.WfUnitPk.ProfileKey) emailTo = BRApi.Finance.Entity.Text(si, oEntityList(0).EntityMemberID, 8, False, False) emailBody = $"[{si.AppName}] - Status Of {sWFProfileName} WF | {sWFScenario} Scenario For {sMonth} {iYear} was changed To {If(oWorkflowInfo.IsCertified, "Certified", "InProcess")} By {si.UserName}" emailSubject = $"FM Task: {sWFProfileName} Certification Status has been changed to {If(oWorkflowInfo.IsCertified, "Certified", "InProcess")}" FBR_ConnectorLibrary.emailSend(si, emailTo, emailBody, emailSubject, emailBody) Thanks, WillCourse Announcement: Applying Dashboard Rules: Concepts and Use Cases
1 MIN READ Course Description: Using Business Rules for dashboards within workspaces, centralizes and reuses logic across the OneStream platform, enabling calculations, validations, and processes without duplicating logic. This module focuses on Business Rules, how they are used within dashboards, and how they work with workspaces, and other OneStream platform components. Delivery Types: On-Demand (OD) Duration: 2 hours, 30 minutes Availability: NAVIGATOR PASSPORT EXCLUSIVE Course Link: Applying Dashboard Rules: Concepts and Use CasesTech Talks: No Code Dynamic Dashboards
On this edition of Tech Talks, Sam Eburn and Jerome Marcq join Tom Linton and Matt Kerslake to demonstrate the power of no code Dynamic Dashboards on the OneStream platform. Learn how features such as Repeat Arguments and Template Parameters can be created without the need for complex code writing. To receive OnePoints for watching this Tech Talk video, please visit the link below: No Code Dynamic Dashboards
