The Evolution to Salesforce OmniStudio

Salesforce acquired Vlocity and now refers to it as Salesforce Industries or OmniStudio.

The platform comprises three primary sections: Digital Experience, Service Management, and Developer Experience, each designed for different use cases and business functions.

FlexCards and Omniscripts are utilised in the Digital Experience layer to facilitate the creation of static or dynamic user interfaces with ease and drag-and-drop functionality.

At the same time, enrollment flows, which capture specific data points at each step, are also considered.

Salesforce OmniStudio Setup and Design Tools

Salesforce OmniStudio provides a comprehensive suite of design tools, all accessible through its App Launcher.

From configuring data adapters and FlexCard designs, everything is easily accessible; even searching for “data adapter” leads directly into its designer mode. Before beginning design work on any new org, exploring existing records is highly beneficial.

Reviewing Accounts and Contacts, in particular, offers valuable insight into data structures; each record has an individual ID, which helps plan how best to fetch and display data using Salesforce OmniStudio components.

Salesforce Objects with Salesforce OmniStudio

Mapping user interface fields to Salesforce objects is often necessary when working with Salesforce OmniStudio; for example, customer information typically resides within a Contact object.

To discover which fields to utilise when mapping customer details into Salesforce objects, the Object Manager in Salesforce Setup serves as a comprehensive data dictionary that lists out all available fields and relationships.

Product managers who lack clarity on which fields to include often struggle to identify the necessary ones. When designing with Salesforce OmniStudio, understanding these nuances is crucial for creating successful products.

Phone numbers require multiple fields with recommendations based on context; mailing addresses typically use auto-calculations with fields like Mailing Street, City, and Country as their starting points – this makes understanding them crucially important when developing.

Fields in Salesforce OmniStudio

OmniStudio makes it efficient and straightforward to navigate Salesforce standard and custom objects. While standard objects, such as Account, Contact, and Opportunity, are preconfigured, custom objects are distinguished by a namespace followed by “__c”.

Installing Salesforce OmniStudio’s Vlocity managed package unlocks access to an extensive set of custom objects and fields explicitly tailored for industries like communications, finance and insurance – these components of OmniStudio make its powerful capabilities clear to you!

Every custom field and object in Salesforce has an associated namespace, which helps developers keep track of its source, especially when multiple packages have been installed onto the Salesforce platform.

Building Applications with Salesforce OmniStudio and Vlocity

Vlocity, now part of Salesforce OmniStudio, was initially an independent provider offering ready-built solutions to multiple industries.

Their integration into Salesforce offered ready-to-use APIs, databases and application templates that were ready-made.

Vlocity provides tools that enable communication companies to develop internet plans and manage customer accounts.

At the same time, Salesforce OmniStudio enables companies to configure products, set pricing attributes, and define product codes without worrying about where their data resides.

Salesforce OmniStudio streamlines the editing process by offering a user-friendly interface that directly integrates with Vlocity APIs, providing a seamless experience that distinguishes it from similar tools on the market. This unique advantage distinguishes it from competitors.

UI with Salesforce OmniStudio Without Writing Code

Creating user interface applications once meant writing extensive code, but now, with Salesforce OmniStudio, components can be easily dragged and dropped together for efficient interface design—an incredible time-saver that allows teams to focus on functionality rather than syntax.

Salesforce supports single sign-on (SSO), making the user experience smoother. While SSO doesn’t directly tie to OmniStudio, it works seamlessly within their ecosystem.

Deploying and Managing Components with Salesforce OmniStudio

After components have been developed in Salesforce OmniStudio, their deployment becomes straightforward.

The platform generates JSON or backend code, which can then be uploaded into Git repositories for versioning control and tracking purposes.

With Salesforce Industries DX, deployments across environments are managed, ensuring consistency while safeguarding configurations during updates. This is essential for maintaining stability.

Building Agent Consoles with Salesforce OmniStudio

Salesforce OmniStudio offered one of the most exciting use cases: creating an agent console for telecom customer service agents to use when handling broadband plans and phones purchased online or in retail stores.

Consider calling customer support after buying broadband plans or phones online — the agent opens an agent console displaying customer details, such as phone number, email address, and mailing address. All neatly organised.

Salesforce OmniStudio was used to design the console, utilising FlexCards and guided journeys. T

he console displays consumer details in the left panel. In contrast, actions such as ‘Update Customer Details’ open Omniscript-built guided flows, enabling customers to edit and save information directly into the database for an engaging, dynamic, and user-friendly experience.

Data Adapters in Salesforce OmniStudio

Salesforce OmniStudio’s data adapter is an impressive backend tool, designed specifically to transform backend operations.

Based on PHP and C# backgrounds, Salesforce OmniStudio replaces traditional code with configuration-based tools, enabling the data adapter to retrieve, load, and transform all types of information for backend operations.

To transform customer details in JSON format into different nodes, the transform data adapter can be an intuitive and efficient solution.

Accessible through the Salesforce App Launcher, its data adapter designer provides visibility into existing adapters within an organisation, as well as ways to manage them.

To obtain configuration data in Salesforce OmniStudio, utilise a data adapter before the HTTP action.

A getConfigInfo data adapter can be created and utilised to gather it from custom settings or metadata; it extracts fields like URL and token, which are then used to construct complete endpoint URLs during HTTP actions.

Once a data adapter is set up, HTTP actions become fully dynamic. When third-party services change their endpoints, all that’s necessary to update Salesforce OmniStudio is to adjust one custom setting — there’s no need for script changes or component revisions.

Extracting Specific Data from JSON in Salesforce OmniStudio

Sometimes, only specific information from the JSON response, like weather data, is required from it.

With Salesforce OmniStudio’s Node Name Search function, it is possible to quickly locate nodes such as ‘main’ for temperature information and refer directly to them within an interface component.

Targeted data presentation helps present only relevant information to users, keeping the interface clean and focused. Salesforce OmniStudio makes extracting and displaying what is necessary a snap.

Salesforce OmniStudio HTTP Actions

Salesforce OmniStudio HTTP actions support parameters. When passed to an STDP action, passing parameters causes it to render dynamically and extend an existing example by clicking an HTTP action and watching its response.

Next in this process should be the display of the received data. Salesforce OmniStudio uses static URLs when performing HTTP actions.

While dynamically passing city names to an action’s URL may be possible, its consistency after deployment cannot be guaranteed and may change over time if an endpoint changes. Should that occur, manual updates would need to be applied after every deployment, which would not be ideal.

Alternative approaches that facilitate managing dynamic values, such as URLs, tokens, and parameters, include custom labels or settings to manage these values.

This way, you can keep configuration details separate from scripts or components; custom settings enable updates without impacting integration procedures or FlexCard updates.

Creating fields such as ‘endpoint URL’, ‘city name parameter’, and ‘API ID token’ allows updates without modification to existing integration procedures and FlexCard.

Working with HTTP Actions in Salesforce OmniStudio

Salesforce OmniStudio utilises HTTP actions before resorting to remote actions for retrieving external information, such as weather updates from external sources, and saving it as a JSON file in Salesforce OmniStudio for later retrieval by remote actions or Apex classes.

Salesforce OmniStudio makes integrating external APIs easy. Configure an HTTP action, and the response is seamlessly included in an input map, providing scripts with enhanced functionality and improving their overall efficiency.

Remote Actions for Apex Logic in Salesforce OmniStudio

OmniStudio components, such as Vlocity, may not always be able to manage complex business logic independently.

When this occurs, remote actions come to the rescue by creating Apex classes, which are then invoked via Omniscripts or integration procedures.

Remote actions within Salesforce OmniStudio enable the verification of permission sets, profile access rights, and custom permissions – a crucial step when users access community websites to request sensitive data.

Creating Apex Classes for Remote Actions in Salesforce OmniStudio

When creating Apex classes for remote action in Salesforce OmniStudio, specific standards should be observed. First and foremost, global classes must implement VlocityOpenInterface.

Based on the package, such as insurance, an interface name is adjusted appropriately, followed by implementation and overrides to necessary methods to ensure seamless integration into Salesforce OmniStudio.

Apex Classes for Salesforce OmniStudio

Building an Apex class for Salesforce OmniStudio begins by creating the required interface, including customising its invoke method according to your specific needs and making at least two methods — usually one each for addition and subtraction.

Salesforce OmniStudio uses the method name passed from Omniscript as input when determining which method to call, making this approach an efficient way to utilise one class for multiple functions.

Apex Classes with Remote Actions in Salesforce OmniStudio

Salesforce OmniStudio makes calling Apex classes via remote actions simple once the flow has been understood.

Create an Apex class, configure its remote action in Salesforce OmniStudio, and pass in parameters containing user information to execute logic inside it – an efficient method that keeps code modular.

OmniStudio excels at seamlessly combining Apex logic and declarative tools, this powerful combination handling complex scenarios expertly and consistently producing positive outcomes.

Invoke Method in Salesforce OmniStudio

Here is an introduction to Salesforce OmniStudio’s invoke method implementation, featuring four parameters that we will walk through below.

The first parameter, methodName, can take any name — methodOne, methodTwo, or ABC doesn’t matter; what matters is how the name will be handled within this method.

Assuming ABC is passed as input via the Salesforce OmniStudio UI, methodOne may be called. All this depends on how the logic defined within Salesforce OmniStudio is structured.

When passing input, such as a method name from the user’s UI interface, Salesforce OmniStudio helps determine which method to execute first.

Mapping Input and Output in Salesforce OmniStudio

Salesforce OmniStudio utilises an input parameter as a central element. It captures all data passed from Omniscript before remote action triggering and stores it all in an input map for reference when searching out specific details in subsequent steps of logic.

On the other hand, OmniScript utilises its output parameter to return data to Salesforce OmniStudio for further processing. After running business logic, an output map populated with key-value pairs is created, which Salesforce uses as its return response map —a more efficient solution.

Executing Remote Actions in Salesforce OmniStudio

Remote actions in Salesforce OmniStudio are decisive. A remote action element can be easily added to an Omniscript script file by dragging and dropping, after configuring it with class name and method name information.

It is then executed, resulting in Salesforce OmniStudio calling its specified method and returning output data.

The action debugger is often used to monitor execution. It displays request data – all the JSON from previous steps that is passed directly from Apex classes – making debugging much simpler and faster.

Debugging and Logs in Salesforce OmniStudio

Salesforce OmniStudio provides in-depth debug logs. Logs can be set up and remotely executed to record input/output data from both Apex classes.

These logs help identify what data is being passed into an Apex class for processing, as well as how it is processed. Salesforce OmniStudio makes this extremely helpful when troubleshooting and refining logic.

Even without explicit parameter passing, Salesforce ensures the data reaches Apex classes successfully – this is incredibly beneficial when troubleshooting logic problems or optimising logic solutions.