Display External Data

Learning Objectives

After completing this unit, you’ll be able to:

• Display data from an external source.
  
• Build a Text Block.
  
• Use a Messaging element in an OmniScript.
  

Display External Data on an OmniScript

You’re on the verge of releasing your Update Account Primary Contact OmniScript. But before you can release it, you get a new requirement: Add weather forecast information for the account’s location plus alerts if there are any hazardous weather conditions.

“In the Update Account Primary Contact guided workflow, I'd like to view weather forecast information for the account’s location and see alerts if there are any hazardous weather conditions.”

Luckily, you’re prepared for this kind of last-minute request. You plan to add the weather information to the top of the OmniScript. 

How does this work? 

To display external data on an OmniScript, start by focusing on the requirements. In this example, you need three things to fulfill the requirement.

• A way to get data from an external source.
  
• A way to display this data on the OmniScript.
  
• A way to add warning messages for hazardous conditions.
  

Now, let’s determine which OmniScript elements meet these requirements. 

One of the reasons OmniStudio Integration Procedures are a best practice for retrieving data is their ability to extract data from multiple sources. Adding a second Integration Procedure before the Step lets you provide the internal Salesforce data (an account postal code) that is needed to get weather data from an external source. You like Weatherbit.io and decide to use its API to retrieve the weather data. 

Now that you’ve figured out how to get this external data, it’s time to choose the best solution to display the weather. Your org already has a weather FlexCard and you can embed this weather card in your OmniScript using a custom Lightning Web Component (LWC) element. 

Knowing this, you decide reusing this card  is the best way to display the weather.

The final requirement is to add warning messages when there are hazardous weather conditions in the account’s location. You decide to use a Messaging element because Messaging elements require a logical condition—or set of conditions—and validation that determine when to display the banner. Once you set Validation or Conditional Views for a list of hazardous conditions, the banner only displays when these conditions are met. You decide to add an Integration Procedure to extract weather data above the Step and add a Messaging and Text Block element to the top of the OmniScript step to meet the last-minute requirements. There will now be two Integration Procedures before the Step.

You’ve planned the way to meet the requirements and are ready to configure the changes.

Embed a FlexCard

FlexCards can be embedded in OmniScripts using a Custom Lightning Web Component element. This element allows you to reuse components you have already developed elsewhere. You already have a Weather FlexCard in your org that displays the current weather for the account with a flyout that displays a five-day weather forecast. Display the current weather and have a forecast available at the click of a button? Yes please! Reusing this card is all a part of the configure once, deploy in multiple places approach of OmniStudio. Note: unlike other elements, custom LWCs only display in an OmniScript preview if the OmniScript is active.

Use Messaging to Display Warnings

You plan to use the Messaging element to display a warning message when local weather for the account matches certain conditions. 

If needed, you could display two different messages based on whether the weather condition is true or false. If the false statement is required, users cannot move forward until that condition is true (you cannot complete scheduling a service call if the weather is below freezing). 

The following table lists the banner types available, and if they are visible if the condition is true (met) or if it is false (not met). Notice the Requirement message type is only available if the condition is false (not met). 

With the messaging complete, you’ve finished building your OmniScript. After activating it you’re ready to deploy it! 

And, just like that, you have a branching OmniScript. Remember, branches make for engaging and meaningful interactions that really guide users through a process. That’s good stuff!

Resources

• Trailhead: OmniStudio FlexCards