Skip to main content

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.

  1. Data Mapper Post Action
  2. Data Mapper Turbo Action
  3. 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.

  1. Data Mapper Post Action
  2. Response Action
  3. 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.

  1. Data Mapper Post Action
  2. Data Mapper Extract Action
  3. 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.

  1. Data Mapper Extract Action
  2. Data Mapper Transform Action
  3. 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.

  1. Data Mapper Post Action
  2. Data Mapper Transform Action
  3. 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:

  1. Response Action
  2. Data Mapper Post Action
  3. 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.

Share your Trailhead feedback over on Salesforce Help.

We'd love to hear about your experience with Trailhead - you can now access the new feedback form anytime from the Salesforce Help site.

Learn More Continue to Share Feedback