Best Practices (and Pitfalls to Avoid) When Using Salesforce OmniStudio
Developing a customer-facing application is no easy task – managing the creation of multiple screens, repeating features, and interactions with external data sources are just a few of the key considerations developers take on throughout the process. For any enterprise that has been in this position, it is a fact how challenging it can be to curate a branded and consistent experience for users.
Fortunately, Salesforce OmniStudio is a powerful set of tools that can help any organization create engaging and branded experiences for users and customers, all without requiring extensive technical knowledge. With features like FlexCards, OmniScripts, DataRaptors, and Integration Procedures, companies can easily build customized workflows using drag-and-drop functionality. In this blog, we’ll share our top five best practices for using OmniStudio to maximize your development velocity, future-proof your solutions, and reduce expenditures.
5 Best Practice Tips for Salesforce OmniStudio
For new users of the tool, or even enterprises considering adopting OmniStudio, these Salesforce OmniStudio best practices below will help maximize your development velocity, futureproof your solutions, and reduce expenditures while using this versatile suite of digital engagement tools. Let’s dive in!
1. Develop with Reusability in Mind & Reuse Components for Efficiency
Salesforce OmniStudio is often used as a platform to build applications with a customer-facing user interface. As such, these applications will consist of a series of screens through which users can navigate. During the development of these screens, developers will find themselves replicating similar features, display areas, and functionality across screens (e.g., view record details, navigate back to a home screen, etc.). If the proper communication tools are not set and the potential candidate components for re-usability are not outlined, there will be multiple FlexCards/OmniScripts that display the same data that will be extracted with different Integration Procedures and OmniScripts. Developers must ensure the use of components like child FlexCards to display repetitive content and reuse Integration Procedures and DataRaptors that return the same data. This will keep development environments clean and performing optimally (it is common to run into performance issues in development environments due to high volumes of unnecessary components).
Reusability can and should be applied to Custom Styles and/or CSS, especially when building applications or consoles that contain interacting FlexCards and/or OmniScripts. Applications should have a branded feel which means that components such as titles, paragraphs, lists, etc., will share the same styling (font family, font weight, letter spacing, colors, …). By setting up Custom Styles and Global CSS classes, screens across applications will be able to reuse styling, saving developers time while setting up front-end components.
2. Plan Data Needs Ahead of Time and Optimize Data Services
One of the first things that needs to be tackled prior to beginning development is data mapping. Understanding and optimizing your data sources is essential to building a responsible and scalable framework. Ideally, all data would be housed in Salesforce, making extract tools more efficient. However, in practice, you’ll likely have to account for external data sources as well. Analysis will need to be completed on the cost and benefits of having various source locations, not only as it relates to your development within Salesforce OmniStudio, but also on the impact to the rest of your business. As an example, if there is a requirement to get data from a weather forecast for a specific location, there will need to be an API that pulls data from an external system. This is perfectly fine as developers can leverage Integration Procedures to easily access this data. However, if considering a scenario where we have an external system that hosts billing information of the application users that needs to be displayed in FlexCards and/or OmniScripts. This is where a key decision needs to be made. Housing the billing data in Salesforce would make the data extraction process more efficient and despite the initial high cost, it will be worth it in the long run.
In conjunction with a prudent and responsible data model, a deep understanding of the data extraction tools is essential. Salesforce OmniStudio has different tools to extract the data needed across the application. It is important to distinguish each of these tools and for Salesforce OmniStudio developers to understand when and where to use each of them. As a quick overview, here are the tools available for data extraction with some of their key features:
- Integration Procedure: Ideal for handling external data and complex extraction processes that require multiple calls. DataRaptors and Apex Classes can be leveraged from Integration Procedures to simplify the process further.
- DataRaptor Turbo Extract: A useful tool for retrieving Salesforce records from a single Object. If you only need to extract data from one object, this is the tool for you.
- DataRaptor Extract: Need to retrieve multiple Salesforce Objects? DataRaptor Extract is the perfect solution for efficiently extracting data from multiple objects at once.
Once the knowledge of the different data tools is nailed down, there needs to be an understanding of sharing data between components. When developing large customer-facing applications, it is quite common to surface the same data in various parts of the application, so when certain common data requirements for specific FlexCards or OmniScripts are present, there should be an examination of the screen flow to analyze previous and following screens to understand if any data is available on that screen that may be useful. That way, the amount of data extraction calls needed on the current and following screens can be reduced. If this approach is followed across all screen flows in the developed application, the resulting application will be lightweight and robust.
3. Do Not Ignore Testing Application Performance
Few things are more irritating for end users than experiencing high load times. It is crucial to complete performance testing, especially on screens that might have complex Integration Procedures and/or populated designs. During testing, a developer might notice that a screen has an acceptable load time. However, it is important to understand that the final product will be used by hundreds or even thousands of users. This means that the number of operations to be executed will increase exponentially, making load times a lot longer than initially expected. So, once the screens are developed and tested, before deploying and making them available to end users, make sure you do some performance testing, which will consider high-traffic scenarios. If high load times are observed, it is time to reengineer the existing FlexCards, OmniScripts and/or Integration Procedures. Remember that performance will be highly impacted by testing location, so not only take into account the user volume, mix, day, and time of accessing the application, but also the physical location of the end users. Having testing executed in a different location than the end users will give unrealistic performance results.
Some strategies to improve the application performance are touched upon throughout this blog, but here are some of the key ones:
- Avoid complex Integration Procedures with repeatable components.
- Leverage Data Tables and child FlexCards when listing records.
- Re-use styling (Custom Styles & CSS classes) and Data sources.
- Keep your environments clean by removing unused components like testing FlexCards.
4. Keep FlexCards Simple and Sleek
It is important that designs are not cluttered and have a clear layout. Cluttered designs will translate in FlexCards having too many components, potentially affecting the response time of FlexCard editing. More importantly, it can confuse end users when they interact with the front end. When working on screen designs, and screen components begin to pile up, it is time to start using components like flyouts that enable screen sections to expand where more information needs to be disclosed. As an example, let us say a developer wants to show the contacts associated with an account. As a requirement, contact fields like first name, last name, address, phone number and other contact related fields of interest need to be displayed to the end user. A problem is encountered for Accounts that have a large list of related contacts, making the screen overloaded. For this scenario, basic fields like contact name and last name can be displayed in the list of contacts and flyouts would be leveraged on each contact to expand and show the rest of the required information. Salesforce OmniStudio will make it easy for the Salesforce OmniStudio developer as the flyout would only need to be set up once.
5. Utilize Testing Environments & Plan Deployments
Even though this is not OmniStudio-specific and more of a general good practice around tech solutions, it is essential that all applications have at least two environments so the required testing can be done without compromising the user experience. As an example, let us look at a scenario where a new navigation item needs to be included in an existing FlexCard or OmniScript, it is important to make sure that the implementation of this change is made in a lower environment so it can be rigorously tested. Once developers and business users agree the functionality behaves and the design looks as expected, it is then time to deploy the updated FlexCard and/or OmniScript to the Production environment, without worrying about end users running into unexpected issues.
Having multiple environments is generally recognized as best practice and widely adopted, and this also applies to OmniStudio. Make sure to have at least three levels (Dev, QA, Prod) to promote your components without any undesirable impact to functionality.
At no extra cost, developers can manually export components from test environments and then import them into higher environments. Realistically, big organizations will need to deploy a lot of components on a regular basis, which is why third-party tools like Gearset and Copado will allow organizations to deploy between environments in a more dynamic fashion. As part of the deployment process, it is a wise option to make use of source control software. Tools like GitHub can offer organizations a component protection mechanism that offers the ability to view on a large scale how components are changing with time.
Make Salesforce Work Better for You
Kenway’s Salesforce OmniStudio Consultants recognize the ability this tool has to help organizations streamline their business processes and improve customer experience. By following the best practices discussed above, such as planning ahead, testing thoroughly, and leveraging the proper tools, we can maximize the benefits of this platform and drive better business outcomes. With continued focus on these best practices and ongoing training, we can ensure that you and your organization are getting the most out of Salesforce OmniStudio and delivering the best possible results for your customers.
If you want to seize the full range of opportunities Salesforce offers, reach out to our Salesforce OmniStudio Consultants experts today.