What is OmniStudio?

Salesforce OmniStudio

Two days back, I accidentally got introduced to OmniStudio as I was searching a little detail about various industry applications that we currently have in Salesforce like Industry, Health, Finance, etc. While there are many good blogs, videos, and trailhead modules specifying how all this thing works, I want to share my explorations and understanding around it after trying a few things in the last two days. Let’s jump in.

Why OmniStudio?

If you are using Salesforce for a long time now, you must already be knowing the capability of the platform in terms of system integrations and implementing custom business flows using Automation (Salesforce Flow, Process Builder Flows), Integrations (Appexchange, Apex Language, External Objects, etc.). While this solve many problems for a business there are challenges in some scenarios like which I actually did implement in 2020 was a LWC+Custom Data Model based guided customer onboarding process using a SaaS API which needed uploading different documents at different stage and got validated using their API. It was completed at a point, however maintaining, customizing and scaling the solution was a real problem. Needed an eye on every aspect of Design, Code, Testing, System Integrations, Integration Error handing which was nice but a little time-consuming and less flexible. Similar things can also be achieved using Salesforce Flows, but they too have a few limitations. You must be knowing this if you have implemented Invokable APIs for Salesforce Process Builder Flows to call External APIs to send/get Data from your ex-systems.

Quick overview around OmniStudio features

  • OmniStudio provides you with some components to quickly build such really complex guided business flows.
  • The components used by end users are FlexCard, OmniScript, DataRaptor and Integration Procedure.
  • DataRaptor(DR): The very first thing that I focused on implementing was Data Raptors. These are components that help you interact (Retrieve OR Load) Salesforce Data with and extra Data Transformation action (JSON→XML, XML→JSON etc.). This is used within the Integration Procedures as Data Source Actions.
  • Integration Procedure(IP): Compose step-by-step procedure to bring in, mix, mash and send data to/from Salesforce (DataRaptor) or External Systems/Microservices (HTTP Action). It’s not just about data, it has access to anything an Apex can access. This doesn’t have a UI element.
  • FlexCard(FC): This is a UI element as the name suggest, however you can add multiple kind of elements like Fields from the JSON response of source Integration Procedures, Text Elements, Images, etc. This cards can be setup in a Parent-Child way such that the Child components can act as Templates and reused in multiple areas. Flex Cards are context aware, i.e. When you embed a Flex card on a Target page, it has access to its record ID. The fun thing here is FlexCards can have actions (for example a button click) which can invoke a OmniScript, Flyout (Modal/Pop Over), etc.
  • OmniScript: This is a guided process which is implemented using the above elements, this also is a UI element however this provides a way to user for interaction like input fields, pick list images, FlexCards, DataTable, etc. This guided process is composed of multiple step, with each step having its own State and can be branched conditionally.
  • While this a superFast introduction, some other important features I would like to mention are: These components can be exported and imported from the UI, are developer friendly, are design friendly (Supports SLDS and NewPort design system), can be quickly tweaked, and they make efficient use of Caching techniques in Salesforce platform. Moreover, the components can also be used externally (ex. Experience Cloud Site).

Demonstration: Flex card fetching Salesforce and External Data

Important references/notes:


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *