Introduction to the Solution Exchange

Originally written by Shawn Stalker, updated by Shawn Stalker & Chul Smith

What is the Solution Exchange?

The Solution Exchange is the distribution mechanism for OneStream Platform software and solutions. It allows users to download pre-created solutions to add extra functionality to an existing version of the OneStream application. The platform section contains all currently supported OneStream Platform installation packages. Think of it like an app store for your phone, which also allows you to download new versions of your phone’s operating system.

The solutions within have been developed by OneStream’s Solution Network team, varying OneStream partners or the greater OneStream community. Partner-developed solutions are supported by the respective solution provider. Due to the various developers, our focus in this chapter will remain on the OneStream-developed solutions.

Figure 13.1

First, a short history lesson…

History of the Solution Exchange

At the very first OneStream user conference (August 2013), we discussed our vision for OneStream during the keynote presentation. At that point, we already had the basis for our first solution and knew that we were on to something. In the keynote presentation, the founders discussed their journey with OneStream using old cell phones to showcase the transition in technology through the years – along with how they came to start OneStream. The smartphone was the perfect analogy for where OneStream was going. Do you need a separate cell phone, flashlight, camera, and GPS? No! And the same should go for financial software. You should no longer need to buy separate financial consolidation, planning, and account reconciliation solutions. It should be a smart system – all in one package – just like a smartphone.

Figure 13.2

In the spring of 2014, at the second OneStream Splash user conference, OneStream released the first incarnation of the Solution Exchange. It was originally called the OneStream Fish Market based on the company’s original fish logo, and allowed users to access OneStream software, solutions, and online video training, as well as link to OneStream support. By the spring of 2016, OneStream had updated its logo, and with it came a rebranding of the Fish Market as the OneStream MarketPlace. In the spring of 2023, the Solution Exchange was launched. This expansion extended the availability of solution offerings from others within the OneStream community. PartnerPlace and OpenPlace were created for this reason, while MarketPlace continued to provide the OneStream-developed solutions. Two years later, the Solution Exchange simplified its model by removing the three “Places”, providing a single location where consultants and administrators can search and download these solutions as well as various platform versions. Figure 13.3 shows the origins of Solution Exchange.

Figure 13.3

When I started at OneStream in early 2013, I was working on a project for one of our first customers. This customer had already implemented Actual reporting and was now adding in their Forecast process. Part of their original Actuals reporting implementation had been a custom reporting dashboard that allowed users to select their scenario, time period, entity, and report from predefined dropdowns. Those selections would generate the reports and display them to the user.

One of the items I was tasked with adding was support for their Forecast data to the custom reporting dashboard. As I had never worked with OneStream dashboards before, I had to basically disassemble the code to figure out how it all worked. It turned out that their Forecast involved more than just adding a new Scenario Type; they were looking to forecast at a much more detailed level. Many of the items on the dashboard that were already working for Actuals would need to be refactored in order to support the new Forecast.

The final version of this custom reporting dashboard turned out to be something that we thought would be useful for more than just one customer. It could be used by all our customers and expand OneStream’s value with minimal effort. With some additional features and documentation, the Guided Reporting (GRT) solution was born.

Figure 13.4

OneStream as a Development Environment

The original intent behind the dashboard and business rule toolset in OneStream was for reporting and workflow customization. Users would be able to create forms to enter data and have dropdowns that allowed selections to be entered into the form. This was also the thought process for the custom reporting solution that we originally implemented. During the process of creating the Guided Reporting solution, we came to the realization that what we had was not just going to be used for reporting and customization. This was a platform for developing OneStream solutions. We had created a full development environment, enabling developers to write software on our software.

Figure 13.5

There was everything needed for OneStream to be a true development platform… just as envisioned at the first conference. There was an interface for creating UI with our application dashboards, a truly integrated development environment (IDE) with our business rule editor, and access to all of OneStream’s BRAPIs. In addition, we had full access to all the OneStream engines, as well as security.

The Solution Exchange itself is a great example of OneStream’s platform concept. Once we started creating solutions, we knew that we would need a store/distribution method for getting the solutions to our user base, and when we started thinking about building a website for hosting a store, we quickly concluded that OneStream itself would be the perfect method for hosting it.

OneStream already has built-in security that can be accessed through the BRAPI, and we could even run other solutions in the MarketPlace as part of the MarketPlace.

On the very first version of the MarketPlace, we also included a solution that could be used online. The section for training videos was the Train Me (TRM) solution, which was used to provide access to OneStream-created video content. This was used to provide video instructions on how to use OneStream and the MarketPlace itself. Additionally, we added a section called Online Solutions into the MarketPlace that contained dashboard accelerators and samples. These allowed users to create starting points for their own solutions. We had turned the MarketPlace itself into a solution that not only allowed solutions to be downloaded but which also allowed users to create their own custom solutions.

Solution Exchange vs. Platform Development

There are two distinct development teams within OneStream: the Platform team and the Solution Network team (previously called the MarketPlace team). When I started with the company, only the platform team existed. As the company was so small, there was no official quality testing team; everyone in the company participated in testing new releases. At the time, this worked well; the early releases were small.

By the end of 2013, I had moved from working on customer implementations to the development team. At this point, I was running the testing for platform releases as well as working on developing the Fish Market and its solutions. This was the beginning of a separate development team that focused on solution development.

Time to Market

The platform development team focused on adding new features, and many of the new platform features would be in process for more than one release. Feature code would be added but not available (or visible in the product) until the new feature was fully complete sometime in the future. Typically, the release cycle for the platform code would be three to four months for these feature releases.

What we found with the MarketPlace solutions was that many of the early solutions were much smaller in scale compared to the platform. With built-in access to the platform infrastructure, we could develop solutions much quicker than the major platform features could be implemented. Solutions to compete with major products in the financial arena could be created and released in less than six months.

Tip of the Spear

MarketPlace solutions became a weapon used by the team to win deals. As the MarketPlace team was able to create new solutions so rapidly, we easily created the new features and functionality needed for prospective deals. The MarketPlace team was beginning to focus on creating these new products in order to expand OneStream markets.

A great example of this is the Account Reconciliation solution, which is now found within OneStream Financial Close (OFC). We already had customers’ books of record for their financial data. If we could reconcile that back to their source systems, we could have a fully functioning account reconciliation system quickly. Why should a financial systems user buy a reconciliation suite and then need to take their existing verified data and load it into another separate system to reconcile it? It’s the same way with your smartphone; you don’t have two separate contact lists – one for texts and one for phone calls – you have one contact list that links to both.

In the spring of 2016, we started working on the initial build using the validated data that we already have in our workflow process as the source for allowing users to reconcile that data back to their source. Account reconciliation was another market opportunity that just seemed to be a natural fit for what we already did. In four months, we had a working prototype that we could demo to get feedback. One of the very first demos was to a group in the office for initial admin training.

In that group was a customer who was in the process of looking for account reconciliation software; they had already made a preliminary selection for a competing product. After demonstrating the solution to the class, the customer was ready to put the competing product on hold and wait for it to be completed. This allowed us to validate that we were on track with our thought processes, and showed how an agile team could quickly create a solution able to compete with products from billion-dollar competitors.

Figure 13.6

Solution Exchange Ties to Platform Releases

Since OneStream-developed solutions in the Solution Exchange are created using the platform as the basis, solutions are tied to platform versions. As the platform team adds new features, we can take advantage of these new tools and components to expand the functionality of our solutions. This allows us to focus on adding valuable new features and solutions without having to develop the toolset as well.

As the platform is our development environment, the Solution Exchange is a customer of the platform team. We request new features just as an external customer would; we go through a similar triage process as well. The main benefit is that – since we are part of the same company – we have more input into updates to the development tools than companies that use external development tools.

The downside of this is that every solution that is released is tied to a minimum version of the platform. Every time the Solution Exchange uses a new component or BRAPI added by the platform, we can only use that solution on servers running that same version of the platform or higher. This is due to the new component/BRAPI only existing in that new platform version. The solution may not work properly and may even fail to import on an older version of the platform, depending on the new components being utilized in the solution.

The labeling we use to identify each Solution Exchange release represents the linkage with the platform versions. A normal solution would have the following version: PV620-SV100. This represents platform version 6.2.0, solution version 100. That means that this solution will only work with platform version 6.2.0 and greater, and that this is the first version (100 version) of the

6.2.0 release.

Development Process

Outside of release schedules and development time, the Solution Network and platform development teams are really very similar. Both are structured such that they have multiple sprint teams that each focus on an area of the product or a solution. Each sprint team is made up of developers, quality testers, document writers, and product management. The teams work together to create quality products.

The Solution Network and platform development teams are customer-driven, focusing on making products that meet both customers’ and partners’ needs. Every week we have a team made up of a variety of stakeholders in the company (support, services, customer success, partner management, etc.) that reviews all open requests that have been entered in our defect/enhancement tracking system. Each item is reviewed during this triage meeting to determine the next steps.

The requests come in from either support requests or via IdeaStream. IdeaStream has its own section on the OneStream Community website that allows users to submit enhancement ideas. Additionally users can browse other submitted requests and upvote them. This allows us to

Introduction to the Solution Exchange identify what items customers find the most valuable so that we can prioritize those requests during our triage meetings.

During these meetings, the attendees can bring up any other open item or rejected enhancement for discussion. This request may come from a partner or customer who is looking to get guidance on when a new enhancement will be coming, or maybe someone stating the reasoning behind a rejected item to show its value to the community. Many times, a feature that was dismissed is reopened and added after a solution has evolved and new use cases come to light.

Any bugs are assigned to a quality assurance tester to replicate. If the issue is replicated, then the QA works with development to determine if there is a workaround that can be given to the customer as an interim solution. If the issue cannot be replicated, the QA works with support to help determine if the issue is a configuration issue or if the QA team needs additional customer files to replicate the problem. In the end, if the issue is a bug that requires a code change to resolve, it is approved and assigned to a release.

Any enhancement or new feature requests that come in are discussed with the team to determine if the request is a very specific use case (that does not apply to the majority of customers) or if this is a needed component that we did not originally define when the solution was created. If we think that a request only applies to a very specific use case, product management works with our subject matter experts to verify the customer request and determine if the request can be handled in a more innovative manner than was originally defined in the request.

Enhancement requests come in from both customers and partners, and sometimes from partners on behalf of a customer. In many cases, partners have modified or customized a solution to add functionality that a customer is looking for in a solution, instead of putting in a request to OneStream. In most cases, this should be avoided as it causes problems with support for the solution going forward. When new versions of a solution are released, customers with modified solutions will find themselves needing to attempt to make the same changes again in the newer versions. In some cases, the code can be changed so much that the original modification may no longer work, leaving the customer stranded.

When partners get requests from a customer to modify a OneStream-developed solution, or do this to meet a customer requirement, they should reach out to OneStream support first. This allows the development and product management teams to view the request and propose alternate solutions, whether that be a design change, or potentially a temporary code workaround that can be implemented in a full feature in a future release. This avoids customers feeling upset about their solutions not working properly, and their requests get to help make the solutions that much better.

What’s in the Platform Section?

The platform side of the Solution Exchange is the download site for the OneStream Platform software. It contains download links that allow users to download any of the currently supported versions of the platform, as well as all related content.

Figure 13.7

On the Platform page, there are six tiles for downloading platform installation software, as well as reports and reference material.

• Client Software – contains installation files for the Excel add-in, OneStream Studio Report Builder, OneStream Desktop, and the silent install packages for automating the installation of client tools.

• Self-Hosted Server – contains the installation files for the OneStream servers. Additionally, this contains all documents related to installing on-premise.

• Smart Integration Connector – contains the installation package for OneStream Smart Integration Connector.

• DLL Packages – contains the ERPConnect DLL, used when connecting to SAP.

• Release Notes – document detailing new and changed items for the selected release.

• Documentation – links to OneStream documentation for the current platform version available including the Design & Reference Guide, Platform Guides, Solution Guides, System Guides, etc.

What’s in the Solution section?

The Solution area in the Solution Exchange holds, as you would expect, all the available solutions for download. They are broken into categories such as Financial Close, Advanced Analytics, and Planning.

Full solutions are the primary focus of the Solution Network development team. These solutions can be described as separate software products. They can involve a consulting engagement with an implementation team and application design. While they may use or access financial data from within OneStream, the main functionality of any solution is completely separate from the platform, and is accessed through custom screens that have been created specifically for that solution.

Financial Close (OFC) is a good example of this. Even though it is free within the Solution Exchange, it’s a full product with its own dedicated development team. It has even been the main reason for purchasing OneStream when customers want to implement OFC before implementing budgeting or Actual consolidations. This solution can be compared to some of the main products from our competitors (that sell for millions of dollars).

While solutions can be complex and require a full implementation and design, many are simple tools that add useful functionality to OneStream. For example, the Cloud Admin Tools (CAT) solution’s main purpose is to provide users with the ability to maintain their cloud users and applications on their own… without intervention from the OneStream Cloud support team. This solution can be downloaded from the Solution Exchange and installed in a customer environment with no support or implementation.

Figure 13.8

What Makes up a Solution?

Solutions are made up of multiple OneStream components. The two main components that make a solution are dashboards and business rules. These two items make up the user interface and logic behind the solution. Occasionally, other components such as Cube Views, metadata, extender rules, or data management tasks are included.

When you download a solution from the Solution Exchange, you get a zip file that includes the Solution ID (e.g., – OFC, ACM, etc.) and the solution version information. Inside this zip are all the files that make up the solution. Most solutions can be directly imported into an application, and any solution will be ready to setup and configure. There are a few that also contain other files in the main zip, and the zip file cannot be imported directly into an application. Users should read the installation instructions shown in the Solution Exchange prior to installing a solution for the first time.

With solutions where the downloaded zip file can be imported directly, the only contents are XML files. The components are named based on the objects from OneStream that they contain. For example, a file named ExtensibilityRules.xml will contain extensibility business rules, and DataManagement.xml will contain data management steps and sequences. The heart of the solution is usually going to be ApplicationDashboards.xml, as this contains the dashboard maintenance unit and the three main dashboard types that interact with dashboards (dashboard dataset, dashboard extender, and dashboard XFBR string rules).

Workspaces

Workspaces are the framework for building OneStream solutions. They store maintenance units and facilitate development by providing an isolated environment for developers to segregate and organize solution objects. Workspaces provide an isolated environment in which solution developers and creators can develop multiple solutions to solve complex business processes. Each Workspace can be made up of multiple maintenance units, so multiple solutions can be housed in the same Workspace. Additionally, this allows users to have multiple instances of a solution in different Workspaces without causing object naming conflicts.

Dashboards

Dashboards – and the components that they include – are the visual interface for solutions. The dashboards are arranged to hold components and other dashboards. All these items are contained in one Workspace, and each solution is made up of one Workspace. The Workspace contains maintenance units, dashboards, Cube Views, components (buttons, combo boxes, grids, reports, etc.), data adapters, assemblies, parameters, and files.

Dashboard Organization and Naming

All dashboard objects that are within a maintenance unit are required by OneStream to have a unique name. Solution dashboard naming is specifically designed to aid in the layout of the user interface, as well as ensure object naming uniqueness. When designing dashboards and dashboard groups for a solution, we have standardized object naming.

Dashboard groups are named based on the screen content. Each dashboard group is a self-contained screen, as all the dashboards that are displayed on the screen are included in the one dashboard group. Each group has a suffixed extension on the name that includes the solution abbreviation in parentheses, for example, One Place (UTM). In larger solutions (e.g., when there are a lot of groups), this is extended to include an additional character to denote the type of group or component.

• Administration groups should have their abbreviation end in an A.

• Analysis groups should have their abbreviation end in a Y.

• Help groups should have their abbreviation end in an H.

• Settings groups should have their abbreviation end in a T.

• Setup groups should have their abbreviation end in an S.

• View groups should have their abbreviation end in a V. See below for several examples.

Figure 13.9

Dashboard names are designed to keep related dashboards together and related to their placement in the container dashboard. Standard dashboard naming is broken into three parts – prefix, main, and suffix – each separated by an underscore.

The prefix section is used to organize the visual layout on the application dashboard administration screen. The top-level dashboard in a group is prefixed with a 0 to ensure it is displayed at the top of the dashboard group, as this is normally the dashboard that is referenced by other dashboards.

Dashboards within dashboards should be listed as #a and #a#, again to keep things together. The main section is meant to be a meaningful description of the object – what the dashboard is going to display. This may range from “Header” to “Toolbar” to “Content”. The suffixed section is simply the same suffix used on the containing dashboard group. See the example below:

Figure 13.10

Component Naming

Components also have standard naming in order to ensure the same unique object naming. Each object is prefixed with a standard three-letter abbreviation (denoting the object type) and suffixed with the three or four-letter solution abbreviation, separated by underscores. Originally, we used the prefix to add the ability to sort all components of the same type together in the application dashboard screen for a given solution. The need for this was removed, however, when the platform team added grouping for the component types. Nonetheless, the prefix is still used when adding components to a dashboard as well, as it’s a good identifier for objects when looking at the object tree in design mode.

Component Types

Figure 13.11

Business Rules

Business rules are the main logic behind solutions; they provide all the actions that happen in a dashboard. When you process recs in Account Reconciliation or a task is completed in Task Manager (UTM), it’s a function in one of the business rules that is doing the heavy lifting. There are three main types of business rules that are used in solutions: dashboard dataset, dashboard extender, and dashboard XFBR string. Each of these business rule types has specific functions, but they are coded so that they can talk to each other. This allows us to create core functions in one rule and share the use of those functions with the other business rules.

Dashboard Dataset

Dashboard dataset rules are used to create datasets and return them back to the calling component or function. The main uses in solutions are for reporting and populating component lists. For example, combo box and list box controls have a bound parameter that provides the list of data that each component will display. The parameters can either be defined manually by typing in a hard-coded list, running a SQL query against a database, or processing a dashboard dataset function. The function may simply be to run a different SQL query, but the benefit is that you can control it programmatically. This allows you to change the query dynamically based on user input.

The standard naming format we use for this type of business rule in solutions is

XXX_HelperQueries (where XXX = the selected solution code, as described above). Common dashboard dataset uses:

• Combine different types of data for a report.

• Build programmatic data queries (e.g., analytic plus SQL).

• Conditionally build data query reports.

• Conditionally build data query for parameters.

• Create data to display in advanced components (map advanced charts, etc.).

Dashboard Extender

Dashboard Extender rules are used to extend the functionality of dashboards and components. This is the primary business logic for the solution. When we want to click on a dashboard component – and have it do something (update a value, process data, etc.) – a Dashboard Extender is utilized.

Functions are defined in Dashboard Extender rules, and these functions are then assigned to the dashboard component in the server task property. When the button is clicked, or a grid is saved, then the function that was assigned to the specific component is run. This allows us to control how the dashboards function. Additionally, Dashboard Extender rules are often applied to launching dashboards, allowing us to set specific values when a dashboard is opened. The standard naming format we use for this type of business rule in solutions is XXX_SolutionHelper (where XXX = the selected solution code, as described above).

Common Dashboard Extender uses:

• Execute a task when the user clicks a button.

• Perform a task and show a message to the user.

• Perform a custom calculation.

• Upload a file from the end-user’s machine.

• Include page state to store parameters and values about a specific dashboard page instance.

Dashboard XFBR String

Dashboard XFBR string rules are used to process conditional dashboard parameters. Most dashboard components have properties that only allow selections from a predefined value list. However, when the value list is stored, it saves as a text value. This type of rule allows us to replace the stored text value with a conditional rule. For example, on many solutions, we have a settings button that should only be visible to administrators. However, button components have the property IsVisible where we can only enter True or False. In this situation, we can replace the True

/ False with a rule that checks if the user is an administrator; if they are, then it returns True. When the dashboard is rendered, the rule gets processed and returns the result. The button receives that result and is displayed or hidden based on user security. The standard naming format we use for this type of business rule in solutions is XXX_ParamHelper (where XXX = the selected solution code as described above).

References to Other Business Rules

Most solutions utilize common functions that are defined in a Dashboard Extender business rule. The public functions defined in the shared business rule can be referenced and executed from other business rules. These shared functions create a set of standard helper functions and centralize maintenance of this shared logic.

In order to create a reference from one business rule to another, navigate to the rule calling the shared function and add a declaration in the Referenced Assemblies field of the Properties tab. The syntax used in the referenced assemblies field requires a BR\ prefix and the business rule name to reference (e.g., BR\RCM_SolutionHelper). Once added, an instance of the shared rule is declared in the calling function. This instance can be used to call any public function defined in the shared rule.

Solution Exchange Access

When new customers join OneStream, they go through an onboarding process with the customer enablement team. This process involves identifying two or three users who will be provisioned for access in the Solution Exchange. Typically, the import/export functionality (used to import solutions) is secured to administrators within customer environments. As such, the users granted access are typically administrators for the company, although any user in the company can be granted access. The customer enablement team will provide user login information for each user that is provisioned.

The Solution Exchange can be accessed from the OneStream Software webpage (www.OneStream.com) by clicking on the Solution Exchange link (see Figure 13.12).

Figure 13.12

Environment Considerations

Before beginning the installation of any solution, it is important to decide whether to build directly in the production OneStream application, or in a separate development OneStream application. The primary advantage of building in a production application is that you will not have to migrate the resulting work from a development application. However, there are intrinsic risks when making design changes to an application that is being used in a production capacity, and this is seldom advised. As a best practice, use a development OneStream application to build complex solutions.

If you do implement in a development environment, you will need to migrate the implemented solution to production before going live. Implementation and migration advice for each solution are included in the instruction documentation. Users need to read the instructions and carefully consider any impact prior to implementing in development or production environments.

Another major consideration, when implementing a solution, is the impact on the environment infrastructure. Solutions from the Exchange can put additional strain on servers due to processing. As the solutions normally utilize general server processing, you need to be aware that infrastructure requirements may need to be revisited in order to ensure a performant system. You also need to consider who will be using the solution when evaluating infrastructure, as many solutions in the Exchange are used by a different set of users to those originally defined. For example, the people who perform account reconciliation may not necessarily be the same users performing the financial close. This can mean that there are additional concurrent users in the system, potentially requiring a review of your infrastructure.

Upgrading and Maintaining Solutions

OneStream-developed solutions are regularly updated with enhancements and bug fixes. Our product management team defines the new features being added with each new release. To get these new features and bug fixes, users must download the new version from the Solution Exchange and install it into their environment. From the solution download screen, users can view the release notes for each available version of a solution. Each release note document shows the changes that are included in the release, as well as a deployment section that details the instructions for installing the new version.

Occasionally, the instructions will require an uninstall of the previous UI prior to installation. This is normally due to object naming changes in the dashboard objects. When solutions are installed, they do not load as a replacement; they load via merge. So, if a dashboard or control is renamed in an updated release, and if the old version of the solution was not removed prior to installation, the originally named object in your application will be left where it is. This can lead to problems in the future if the old object is added in a later release.

After installing the new version of the solution, users are shown the standard setup screen when the solution is run for the first time. Normally, when a solution is installed for the first time, the table creation button simply creates the required tables. When a solution is upgraded, however, the new version may require changes to existing tables or the addition of new custom tables. If this is the case, the table creation button will detect the prior installation and will update the table accordingly.

New installations of solutions also require users to specify multiple settings prior to use. OneStream-developed solutions store these solutions in parameters. These parameters are overwritten when an upgrade is imported. To reduce the need to apply the prior settings after every update, we also save settings to a custom table when the settings are updated. After any schema update, these settings are restored to the dashboard parameters to remove the need to re-enter them again.

Adding Multiple Applications

Occasionally, users need to install multiple copies of the same solution. This is normally done in order to limit access to specific portions of OneStream data. As many solutions integrate through workflows, and restrict access using workflow security, solutions need to integrate through multiple workflows and not share data between them. Since all dashboards, components, and business rules are required to be unique, users cannot normally install multiple versions of the same solution.

To handle this situation, we created the MarketPlace Solution Tools (MST) solution. This solution allows users to make multiple copies of a solution. The solution takes every object in a solution zip file and renames them with a numerical extension, creating a new unique name for each object. To use MST, users upload the solution zip to be copied, select the instance number to be used, and then click copy to create the new instance. The new zip that is created can be imported into an application, and the solution will not conflict with the original solution.

Figure 13.13

Starting with platform release 5.0.1, the ability to encrypt business rules was added. New solutions released for the first time (and a few older solutions) are being encrypted in order to prevent changes from being made to business logic. This was done in order to ensure that solutions are maintainable for all users. If a user was to make changes to a business rule, they could potentially alter the output of the solution in a negative manner. As customers rely on these results – in the same way that they rely on financial data – it is of the utmost importance that solutions provide the results as envisaged and designed by the Solution Network team. For these encrypted solutions, if a copy is desired, users can contact support to have instances provided.

Customizing Solutions

Modifying Solution Exchange Solutions

A few cautions and considerations regarding the modification of solutions:

• Major changes to business rules or custom tables within a solution will not be supported through normal channels as the resulting solution(s) are significantly different from the core solution(s).

• If changes are made to any dashboard object or business rule, consider renaming it or copying it to a new object first. This is important because if there is an upgrade to a solution in the future, and the customer applies the upgrade, this will overlay and wipe out the changes. This also applies when updating any of the standard reports and dashboards.

• If modifications are made to a solution, upgrading to later versions will be more complex, depending on the degree of customization. Simple changes, such as changing a logo or colors on a dashboard, do not impact upgrades significantly. Making changes to the custom database tables and business rules – which should be avoided – will make an upgrade even more complicated.

Custom Event Handler

With the addition of encryption to business rules, we knew that we needed to provide a mechanism to allow some customizations. To support this, we added custom event models to encrypted solutions to select OneStream-developed solutions. Some solutions interact with the platform and cloud environment at such a deep level that we do not allow any changes to the code, in order to protect the OneStream environment (e.g., Cloud Admin Tools). The solutions that do enable custom event models have information in their help documentation that details how to enable custom events.

The custom event model is a separate custom event business rule that references the solution’s main Dashboard Extender rule. It allows users to add custom processes before and after select events. For example, you can add an event that sends an email after a specified button is clicked, or which validates data in a grid prior to a save.

Integration

Most Solution Exchange solutions require some integration with the OneStream environment in order to work properly. In most cases, it is simply adding a custom workflow and pointing to a dashboard in the solution. This allows the solutions to use built-in workflow security to limit access and provides users with a guided experience that they are used to in OneStream’s data loading process.

In account reconciliation, for example, the setup involves creating a new scenario and assigning it to an unused Scenario Type (Model in the reference below). This is the scenario that will be used to process account reconciliations. Creating a new Scenario Type allows users to re-use existing workflows and simply update the Scenario Type security to limit the users that can access it. From the Workflow Profiles screen, the administrator selects the workflows to be used with RCM, sets the Workflow Name to Workspace, and assigns 0_Frame_RCM_OnePlace as the Workspace Dashboard Name.

Figure 13.14

Testing

Each solution that is released by the Solution Network team is tested by a team of Quality Assurance engineers. Each development team works to create high-quality code, but – as with other software – this needs to be tested to ensure a quality product. We test not only that the new feature works the way the ticket says it should, but we also test for negative use cases where the developer may not be expecting a user to enter an incorrect value or select a certain combination of options.

We’re looking to cover all the bases to ensure that users can rely on our software right out-of-the-box.

Even though each solution goes through quality testing during development, we recommend that users install any update on a development server prior to installing it in production. This allows users to verify results within their own environment before making a change that cannot (potentially) be rolled back. For non-OneStream-developed solutions, testing is left to the provider of the solution. OneStream does not test or certify these solutions. The solutions are code scanned to ensure that they comply with development guidelines but the developers of the solutions are responsible for functionality.

Solution Exchange Enablement

In addition to developing the roadmap for the Solution Network team and providing guidance on new feature development, the product management team is responsible for product enablement. For each release, the product management team creates the marketing and knowledge transfer for a given solution. This enablement ranges from release notification emails to webcasts and online videos.

After a solution has been released on the Solution Exchange, the product management team sends out a release notification internally to all employees so that everyone is aware of the new product or update. Brand-new solutions are demonstrated internally to ensure that all teams have all the information they need to support and market the new product. After the internal teams have been notified, they notify customers and partners of the release. For the initial release of a solution, an email is sent to all customers detailing the solution and its uses. Solution releases that are only updates of existing solutions are only sent to users who have previously downloaded the solution. Notification emails include key new features and a copy of the release notes.

The product management team also creates Academy videos for major solutions. These videos show how solutions work, as well as setup and design considerations. OneStream Academy delivers the information needed on-demand, which enables the OneStream community to learn via a self-serve approach. The OneStream Academy is available free of charge for those OneStream administrators and implementation consultants who attend the Application Build or the Power User Reporting Class.

Key Takeaways

The customization of solutions should be avoided, and the custom event model should be utilized whenever possible. Prior to making changes, please reach out to support to determine if there is a better design/method to achieve the desired result. If not, support can enter an enhancement to update the solution to try to meet your requirements. Users get more reliable, maintainable solutions, and new features get to be shared with the entire community.

Always consider your existing environment when implementing a new solution. Adding a new solution can have an impact on the amount of data being processed as well as the number of concurrent users. This may require additional server resources or additional OneStream licensing. The OneStream support and cloud teams can help with this type of request.

The MarketPlace Solution Tool (MST) provides an efficient way to copy an existing OneStream-developed solution; it enables multiple solution instances to coexist in a single OneStream Application. This provides the flexibility for different business units (within the same OneStream application) to segregate and secure their data.

Epilogue

One of the things I love about having joined OneStream early on is all the celebrations that truly represent this group of people.

In my second year with OneStream, we closed our first million-dollar deal near the end of December. This was, of course, a reason to celebrate. A $20B international company having the faith to buy financial software from a startup located in a small office in suburban Michigan even more so. So, in true OneStream fashion, we head to our local bar.

However, we don’t celebrate with Champagne; we instead opt for black velvet (Guinness and Champagne).