Salesforce External Services: Configuration for Admins
If you’ve ever dealt with Flow-based integration in the past, you might’ve heard terms like External Object and External Service in Salesforce thrown about a lot, or even conflated.
Both the External Object and External Services let us expedite operations to third-party services.
Here a quick review of some taxonomy:
External Objects:
They’re similar to Custom Objects, except they map to data that’s stored outside your Salesforce Org from within the CRM. Every external object depends on an external data source definition to link to external databases.
External Service:
This is a powerful administrative tool for no Code API usage. In the coming sections, we’ve used External Services to connect to a service of your choice and invoke methods based on the external source via Flows.
Oftentimes, the idea of API deployment conjures complex, code-heavy implementations.
But Salesforce’s External Services let even Accidental Admins use no-code API solutions to configure APIs with schemas.
What even is a schema?
Broadly, it’s a documented structure of services and methods that we can leverage. More notably:
- A Schema definition is human-readable, structured data.
- It’s comprised of inputs and output types you can include in the calls, or requests, that an Org makes to the external service.
- It also holds endpoint information and authentication parameters for REST-based API web services.
- Schema formats allow External Services to process the data so it can generate Apex actions.
(Apex actions are what we later use for I/O in Flows).
Configure External Service :
Schema considerations to use External Service-generated Apex Class through Flows
- There’s a 100,000 character maximum limit.
- Only supported methods justify inclusion.
- Parameters must be named.
- You can’t use nested or complex Objects as inputs or outputs in your service.
- Every property must be assigned a value.
- Header and form parameters aren’t supported.
- Security settings from the schema aren’t supported.
- Supported input and output type in your service(Boolean, integer, double, string, datetime)
- We can use GET, PATCH, PUT, POST, and DELETE methods to query a schema.
Note: Before we register and use External Services, we’ll need to provide a schema that describes the services and methods, and meets the above specifications.
Schema example: https://th-external-services.herokuapp.com/accounts/schema
Purpose: Use External Services to connect to a service of your choice, invoke methods based on the external source via a flow, and import(Swagger or Interagent-based API) data from the service into Salesforce Service.
A general sequence of steps for configuration...
- A 3rd party (External web service provider) shares it’s rest based schema specifications.
- Then, a schema definition is created to describe the API.
- Next, named credentials are created to authenticate to the services endpoints
- The External Service is registered using the named credentials and schema definition. The schema needs to be complete and JSON compliant.
- External Services import the definitions into Org and generates Apex Actions that are made available in a Lightning Flow.
Thereon, we can use Apex Actions from within Flows, and every time a Flow executes, an External Service sends the callout and return based on schema definition.
… and walk-through of these steps as followed by us.
- First, we’ll need to create a Named Credential to authorize the two systems.
As we know already, a schema consists of the endpoint information and authentication parameters for the REST-based API web services. Likewise, we’ll use these in our named credentials.
Caution :
Be sure that you have the Interagent hyper-schema or OpenAPI version 2.0 endpoint information for the service that you’re registering before setting up a named credential.
Go to
Named Credential 🡪 New
Then, enter values for Label, Name, and the “URL to your External web service provider service endpoint that needs to be accessed”.
2. Since External Service will be calling our external services from within a Flow you’ll also need to register the callout endpoint to a Remote Site Setting.
3. Now that we’ve set up all required authentications and registration we’ll move to add External Service from Salesforce
- Switch to Lightning and click Add an External Service.
Enter a service name( description optional).
- Choose a named credential.
- Enter a schema URL path, or alternatively, provide a complete schema.
- Any schema URL path you enter must begin with a forward slash or ‘/’ and be a relative path.
For example: /accountSchema.json.
And again, the schema you provide must be complete and JSON-compliant.
Click Next and then Done.
Result:
A list of available Apex actions with input and output gets displayed.
Also, we can find these generated Apex Actions in the Flow Toolbox.
Finally, it’s time to test our external services apex Actions using Flows
Let’s jump into the Flow Builder to see this in action:
- First, go to
Setup 🡪 Flows 🡪 New Flow
Select Screen Flow and click Create.
2. Based on your requirements, we can create Flow Logic.
And usually, we’ll set up a Salesforce Org(create field) to display results once the callout routine finishes. We then add a Screen Component from the toolbox in Flow Builder to get input from the user as per our schema definition.
To do this, from the toolbox, select and drag Apex Action to the screen.
a. Change Filter Type to External Services to see external services in action.
Apex Actions are the methods pertaining to our service provider, that we can use in a Flow to fish out information.
So, select the method that was described and needs to be used from the External Service Wizard.
b. As depicted here in this trial, set parameters for method invocation by Flow variables if needed.
c. Once you’re finished configuring the Flow, it should look as follows:
d. If there are no alerts in the Debug, it means you’ve just made a successful callout to external service.
Summary
Even with all its flexibility and features of External Services, there are still quite a few key benefits to using Enhanced External Services over them. For example, Enhanced External Services can handle more complex OpenAPI 2.0 schema, nested object types, and send parameters as headers within HTTP requests.
For more information on configuring no-code tools, API services, and practical third party integrations, reach out to us at sales@hicglobalsolutions.com
India 
USA
UK
Canada