Hello,
I recently documented the process of connecting an authenticated external REST API to Salesforce Flow, including the exact configuration and troubleshooting steps along the way.
I've published a guide covering:
o Quick installation of a working example
o Building the integration from scratch using Salesforce's credential and HTTP Callout configuration
o Adapting the Flow to an existing record-triggered workflow
o Modifying the configuration to work with other REST APIs
The goal is to make the process easier to reproduce, particularly for developers who want to call external APIs without writing Apex.
I'd appreciate feedback from people who have built similar integrations: Is this approach useful as a general recipe, and are there any important steps or edge cases I should cover?
The guide details are available here:
https://github.com/ezchx/Salesforce-IndieML-Flow-Integration/blob/main/README.md
The working example uses my IndieML Substance API, but the guide also explains how to adapt it to other APIs.
Thank you for your consideration.
@Richard Horton the recipe is the right shape if the goal is a REST call from Flow without Apex. A few edges are where these guides usually go quiet.
A record-triggered flow can't make the callout on the path that runs immediately. The HTTP Callout has to sit on an asynchronous path. Flow Builder warns you if you drop a callout on the immediate path before that toggle is on. A screen flow, or an autolaunched flow a screen calls, can call out in the same transaction. The record-triggered one can't.
Auth belongs on an external credential and a named credential, not in the flow. The named credential holds the URL, the external credential holds the protocol and the principal, and a permission set has to grant the running user access to that principal. If the user running the flow doesn't have it, the callout fails even when the action looks fine in the builder. I'd stick to the current named credential model rather than a legacy one.
The path, the headers, and the sample response you paste when you create the action get frozen into an external service. If the API adds a field or changes an error body, you rebuild that action. A fault path matters, because a 401 or a timeout otherwise just fails the interview. And if the body isn't a flat JSON object, the sample response is the part I'd spell out. That's where people get stuck when they point the same pattern at a different API.
Bulk is the other one. A record-triggered flow runs an interview per record, so a mass update can fire a lot of callouts. Worth saying what you expect people to do when a couple hundred records save at once. I didn't walk every line of the IndieML repo. These are the spots I'd want covered.
