Design Simple Integration Procedures
Learning Objectives
After completing this unit, you’ll be able to:
- Describe data input and data output for Integration Procedures.
- Explain how to design an Integration Procedure to get data.
- Explain how to design an Integration Procedure to save data.
- Explain how to design an Integration Procedure to get data from an application programming interface (API).
Data Input and Data Output
In this unit, you walk through using Integration Procedures for three different design scenarios. Before we dig into the design scenarios, let’s quickly review the data input and data output for OmniStudio Integration Procedures.
Data Input
Remember, the data source determines which element you use.
For This Data Input Source | Use This Integration Procedure Action Element |
|---|---|
Salesforce Org | Data Mapper Extract Action or Data Mapper Turbo Action |
API | HTTP Action |
Anything that Apex can access | Remote Action |
Data Output
The Response Action element is unique to the Integration Procedure. It passes data back to the tool that launched the procedure. In addition to getting and processing data, you can use an Integration Procedure to output data.
For This Data Output Source | Use This Integration Procedure Action Element |
|---|---|
FlexCards or OmniScripts | Response Action |
Salesforce Org | Data Mapper Post Action (To save data to Salesforce Records) |
Salesforce Org | Delete Action (To delete data from Salesforce Records ) |
API | HTTP Action |
Send Email | Email Action |
DocuSign Template | DocuSign Envelope Action |
Got it? Great. On to the scenarios we go!
Scenario 1: Design an Integration Procedure to Get Data
Imagine that you’d like to see the sample (mock) data replaced with live data in an OmniScript that edits account details. You’d like the OmniScript to be able to extract the data from Salesforce and save any changed data back into Salesforce. So, your task is to design this first Integration Procedure for the Edit Account OmniScript.
There are two requirements for the Integration Procedure.
- Extract Account data from Salesforce.
- Send that data to the Edit Account OmniScript.
Where should you begin? Let’s take it step by step, choosing the Integration Procedure elements that you need to address the data requirements. Don’t forget that, in this scenario, you’re focusing on getting data.
Choose an Actions element that allows the Integration Procedure to get Account data from Salesforce. Here are your choices.
- Data Mapper Post Action
- Data Mapper Turbo Action
- Data Mapper Transform Action
Which one is correct? Well, if you look at the data input table above, you’ll see that because you’re getting data from Salesforce, the Data Mapper Turbo Action is the correct choice. This action calls a Data Mapper Turbo Extract to get data from Salesforce.
Choose an Actions element that allows the Integration Procedure to send that data back to the Edit Account OmniScript. Here are your choices.
- Data Mapper Post Action
- Response Action
- HTTP Action
The correct Actions element is the Response Action. Remember that it passes data back to the launching object (or whatever called the Integration Procedure), which, in this scenario, was the Edit Account OmniScript.
Scenario 2: Design an Integration Procedure to Save Data
Let’s look at our scenario again but change our focus a bit. You’d like the OmniScript to be able to extract the data from Salesforce and save any data that you change back into Salesforce. So, your task is to design an Integration Procedure to save data for the Edit Account OmniScript.
Choose an Actions element that allows the Integration Procedure to save Account data back to Salesforce. Here are your choices.
- Data Mapper Post Action
- Data Mapper Extract Action
- Integration Procedure Action
In this case, the correct choice is Data Mapper Post Action because it saves updated data back to Salesforce.
Scenario 3: Design an Integration Procedure to Get Data from an API
Now imagine that for a Weather FlexCard, you’d like sample data replaced with live weather forecast data that comes from an external source. So your task is to design an Integration Procedure for the Weather FlexCard.
There are a few requirements for the Integration Procedure.
- Get weather data from an application programming interface (API).
- Trim and re-map weather data (many fields).
- Send that data back to the tool that called the Integration Procedure (which is the Weather FlexCard).
Let’s choose the Integration Procedure elements that you need to address the data requirements.
Choose an Actions element that allows the Integration Procedure to get current weather forecast data from an API. Here are your choices.
- Data Mapper Extract Action
- Data Mapper Transform Action
- HTTP Action
The correct choice is HTTP Action. This Actions element can be configured to get data from a Web API.
Now choose an Actions element that allows the Integration Procedure to trim and re-map weather data. Here are your choices.
- Data Mapper Post Action
- Data Mapper Transform Action
- HTTP Action
What’s the correct choice? If you said Data Mapper Transform Action, you’re right! Remember that a Data Mapper Transform can be configured to trim and re-map the data received from the Web API.
Finally, choose an Actions element that allows the Integration Procedure to send that data back to the Weather FlexCard.Your choices are:
- Response Action
- Data Mapper Post Action
- HTTP Action
The correct choice here is Response Action. The Response Action passes data back to the launching object, which, in this scenario, is the Weather FlexCard.
Super job on the scenarios! (*virtual high-five*) Ready to kick the learning up a notch? Head on over to the next unit to get even more hands-on with Integration Procedures.