Agents are powerful productivity tools and their power can extend beyond the Salesforce Platform, thanks to third-party service integrations. In the Spring ’25 release, we introduced External Service (ES) actions for agents, a simpler and faster way to call third-party services from an agent. In this post, we’ll look at the different components at play, the steps required to configure an External Service action, and a sample use case.
Integrate agents easily with third-party systems
Integrating with a third-party service through code requires a good amount of boilerplate code to manage API requests/responses, and format/parse the data that is exchanged. The latter means writing a number of DTO (data transfer object) classes. This code-driven approach has a number of drawbacks:
- It’s time-consuming and is probably not the best use of a developer’s time
- It’s error-prone as you can easily miss a required parameter or introduce a typo in some parameter name
- It comes with a maintenance cost since you have to unit test the Apex that you write
The good news is that there’s a faster and safer way to integrate with a third-party service: you can leverage External Services (ES) with an OpenAPI Specification (OAS) document.
About the OpenAPI Specification (OAS)
The best way to define OAS is to quote the specification directly:
The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.
Thanks to the specification, humans and machines can exchange schema documents (YAML or JSON documents) that describe in detail all of the HTTP requests and responses that a service exposes, along with the exact shape and type of data that is being exchanged. Using OAS documents allows for streamlined integrations and a greater degree of automation.
About External Services
When working on the Salesforce Platform, you can create an external service thanks to an OAS document or a MuleSoft service. External Services (ES) automatically generate the Apex code that you need to implement to interact with the third-party system, and lets you call the requests from Apex or from declarative tools like flows.
You won’t need to unit test the generated code as the service is taking care of it. All you’ll need is integration tests (which you would still need even if you wrote the code yourself in the first place).
Tip: OAS documents are pretty simple to write, so it’s worth considering writing one yourself if the system that you want to integrate with doesn’t expose a schema. There’s a good chance that writing the schema from scratch will be faster than writing, testing, and maintaining the equivalent Apex code.
Before the Spring ’25 release, calling an external service from an agent required that you build a boilerplate flow or Apex invocable action to expose each service’s operation as an agent action. Now, with the Spring ’25 release, you can skip this tedious part and call ES directly from an agent thanks to ES actions.
Configuring an External Service action
Configuring an External Service (ES) action requires three steps, as illustrated in the diagram below:
- Authenticate with a named or an external credential
- Create an external service from an OAS document (or from a MuleSoft service)
- Create an ES action
Step 1: Authenticate with a named or an external credential
The first step in configuring an API action is to configure an external service, and this starts by setting up authentication for the service. This can be done with either a named credential or an external credential.
Once you’ve taken care of the authentication part, you can create an external service by importing an OAS schema.
Step 2: Create an external service from an OAS document
When you create an external service, you start by importing an OAS document, then you select the operation that you wish to import. You can revisit this list later if you decide to use more operations.
Once you’ve created the external service, you create ES actions for the operations that you wish to expose to the agent.
Step 3: Create an External Service action
When creating a new agent action, you’ll notice a new “API” action type. This lets you select an ES operation or a MuleSoft service.
Once you select an operation, you’ll then move to the regular action configuration screen that holds the action description and input/output parameters. If the OAS document that you imported earlier is well defined, it already includes descriptions that are carried over in the action configuration form, so that you don’t have to type them in. Otherwise, you can fine-tune them at this point and confirm the action creation.
And that’s it! These three simple steps are all it takes to configure an ES action. You can add the action to one or more topics and use it in your agents.
Exploring a sample use case
At TDX ’25, we demonstrated how you can interact with a GitHub repository using an agent with External Service actions. Here are the key steps that we followed in case you want to experiment with it. We followed the exact same three steps that we highlighted earlier: setting up authentication and the external service, then configuring actions and topic.
Authentication
We started by generating a GitHub fine-grained Personal Access Token (PAT) for our repository.
We then used this token to configure an external credential. Finally, we declared a named credential using the https://api.github.com API endpoint and our external credential.
External service
We imported a simplified version of the GitHub REST API OAS in which we hand-picked a couple of operations as the full schema was too large to be imported (there’s a maximum upload size of 10 MB in Salesforce and the GitHub APIs are fairly rich).
As you can see in the screenshot above, the descriptions (truncated for brevity) are coming directly from the GitHub docs. This is great because these detailed descriptions help the agent understand the purpose of the operations and the parameters when we convert them into actions.
Actions and topic
Converting the operations into agent actions is very simple as all of the descriptions fields are pre-filled based on the schema descriptions. All it takes is a couple of clicks to get those actions configured. The only two things that are left to configure are:
- Selecting the default conversation output (this is generally the parameter that is associated with the 20x/30x success response)
- As a best practice, requesting user confirmation when taking potentially destructive action like merging a PR
Once the actions are configured, we can create a dedicated “GitHub Assistant“ topic and add the actions to it. Here’s a screenshot that illustrates how we can list pull requests (PRs) from a repository and merge one. Remember that not a single line of code was written to achieve this scenario!
Watch Agentforce Decoded
In the video below, we’ll walk you through how External Service actions allow you to call third-party systems from agents without writing a single line of code with a demo of how an agent interacts with a GitHub repository and manages Pull Requests with External Service actions.
Conclusion
External Service actions are a great way to expand the power of your agents without code. Thanks to these actions, you can integrate with third-party systems to OAS documents. Remember that even if the system that you want to integrate with doesn’t offer an OAS document, you can still write your own. Often, this can be faster than writing the Apex code for an integration (and the related tests), and it will be easier to maintain in the long run.
Resources
- Agentforce Decoded Video: Call Third-Party APIs with External Service Actions
- Documentation:
- Trailhead: Access Business Processes with External Services
About the author
Philippe Ozil is a Principal Developer Advocate at Salesforce, where he focuses on the Salesforce Platform. He writes technical content and speaks frequently at conferences. He is a full-stack developer and enjoys working with APIs, DevOps, robotics, and VR projects. Follow him on X, LinkedIn, and Bluesky. Check his GitHub projects.
