HTTP Callout in Salesforce Summer 23 – POST (Beta) – 3/3

Now, you will build the flow you will host on the community (digital experience) site.

Important note: We will set this flow up to run at the System context without sharing under the Advanced Flow settings.

This simple flow gets an opportunity using the record Id as input and displays critical field values on the screen. Note that a decision is built to handle no or invalid recordId input.

Here is what the Display Text component looks like in the Screen Element.

Once you complete your flow and activate it, create a public community (digital experience) site and add your flow to the main page. Several steps must be followed to set up guest user access properly. We will not go into these steps in this post. Comment below if you need a follow-up post with detailed steps, please.

Once you set up your community, you can pass the recordId as a URL parameter to your flow to see the Opportunity record field values on your screen. You see the long URL in the browser address bar below.

Now, set up a simple record-triggered flow to populate the URL (long URL) field on the Opportunity record. Here is how you do it.

Now set up another record-triggered flow to send an email with the short URL to the owner of the record.

Your email action looks like this in Summer 23 (Yay!).

Your email body text template will look like this.

Your email will look can be seen in the image below. You may think it is silly to shorten the URL by looking at this since we can hide it in an HTML email. That is correct, however, the actual value add is when you need to text (SMS) the link. Short URL looks much better.

After debugging and activating all your flows, you can create a new Opportunity like the one below. Hint: Cloning and modifying a few field values work well when testing.

Voila: Your long URL and short URL are populated, and the email was sent to the record owner’s email inbox.

Enjoy

Note: These posts were written as a result of a collaboration between Josh Dayment and Andy Engin Utkan. I want to thank Josh Dayment for his relentless efforts and countless trials to get this demo to work.

HTTP Callout in Salesforce Summer 23 – POST (Beta) – 2/3

In the flow builder, you must add an action element for the HTTP Callout.

Before you do that, let’s set up the Named Credential the Callout needs.

In setup, go to Named Credentials, select the second tab for the External Credentials, and click on New.

Set up your External Credential as follows.

Per Bit.ly API documentation, your header must pass the Access Token to the Bit.ly API. Generate your Access Token on Bit.ly, as seen below.

Your Access Token will be saved in Principals under Named Credentials. Set it up as follows.

Paste the Access Token form Bit.ly into the value field.

Now your Principle is ready to be used.

The Bit.ly API expects the Access Token to be passed in the header. This is the header section that you will need to set up.

Create your first custom header as follows.

One more custom header is needed. Set it up exactly like in the image below.

Now you are ready to complete your Named Credential setup.

Having set up all parameters the HTTP Callout needs, go to your flow to create the action. Insert an action element and click on “Create HTTP Callout”.

Give it a Name and choose the Named Credential you created. Click Next.

Set up the following parameters.

Get your example request and response JSON here: https://dev.bitly.com/docs/tutorials/shorten-customize-links/

Paste the JSON and click on Review. Hit Done.

Do the same thing for the response. This will create the Apex Defined Variables.

You should see two checkmarks after you click on Done above. Once you complete these steps, your HTTP Callout will be ready.

Now let’s set up the remaining flows and the community (digital experience) site.

Please continue to the third post by clicking here.

HTTP Callout in Salesforce Summer 23 – POST (Beta) – 1/3

HTTP Callout in Spring 23 got many people excited. The blog post and the video by Josh Dayment and I drew quite some attention. We heard one criticism for this functionality: the solution was incomplete without the POST method.

With Summer 23, the Salesforce Flow Product Team not only moves the GET method to GA, but also gives us the POST method in Beta.

The use case we picked for this demo is based on a real-life client requirement. The client wants to shorten the long URL links before they send them to customers via email or text. Text (SMS) requirement is very important because we cannot hide the long URL behind a short label there since SMS does not support rich text. I don’t have texting set up in my preview Org, therefore, I will demo this using email.

The solution consists of many parts. The list is as follows:

Bit.ly is the service that supports an API with a POST method to shorten URLs. We will need an account with Bit.ly. The good thing is they allow us to use the service for free until we reach a certain number. (1)
A record-triggered flow with an async path that uses the HTTP callout to Bit.ly to shorten the URL (2)
A public digital experience (community) site that houses a screen flow to display the critical field values for the Opportunity (3)
A screen flow that runs at system context without sharing to show the critical Opportunity field values on the community site. (4)
A simple record-triggered flow to create the long URL on the record (this can also be a formula field) (5)
A simple record-triggered flow that generates the email with the short link. (6)

And a few custom fields on the Opportunity object: URL (long) and Short URL text fields and a Short URL Requested checkbox field.

First, we go to Bit.ly to create a free account. They have API documentation available. However, I cannot say the documentation is very clear. Here is the relevant settings page we need to create the access token for the API.

*I wiped my values from the screenshot; you will need to copy yours by going to this screen.

We will come back to this later.

Let’s walk you through the flow that will execute the HTTP Callout.

Create these custom fields on the Opportunity object:

URL (Text)

Short URL (Text)

Short URL Requested (Checkbox)

Then create the HTTP callout async record-triggered flow.

This is how the flow looks after it is completed.

Set up the start element as follows.

Build an assignment element to assign field values. You will assign the input parameters Bit.ly API needs to the Apex defined variable that the “Create HTTP Callout” builder provides us. Initially, enter a fixed URL here, such as SalesforceBreak.com, until you can get the flow to work without issues.

Get your group Id from Bit.ly from your browser address bar when you display this screen here.

The only input parameter that the callout action needs is the Apex defined variable.

The short URL is again inside an Apex defined variable under 2XX>link. We will update this value to the short URL custom field of the Opportunity record.

But you can do all this after properly creating your HTTP callout action. And that requires a few steps.

Read the next post to learn how the HTTP Callout action is set up.

Please continue to the second post by clicking here.

HTTP Callout (Beta) in Salesforce Spring 23 – GET

With each new release lately the Salesforce Flow team has been bringing some amazing features. I am really excited about the introduction of HTTP Callout (Beta) in Spring 23′. It really starts to open up the possibility of more resources for admins to start doing more with clicks and not code. This allows an admin directly inside of flow to make an HTTP Callout to perform a Get on an external system previously this would require either an invocable apex action or an external service be created in Salesforce. Andy and I took sometime over the last couple of weeks to test it out and you can see our video here to see our discussion and brief demo but let’s take a deep dive walkthrough on how we configured it and the steps to take. For this testing and demonstration we found a simple api that has a free use tier that allows for a set number of callouts to validate a phone number and return validation information you can find more on Api Layer and the documentation here.

Before you can create an HTTP Callout you first need to create a what’s called a Named Credential a Named Credential is what Salesforce uses to validate you are able to use the external service you are making the call to.

Step 1 in Setup go to Named Credentials

Step 2 Click on New (At the time of this post New is not working in Pre-Release Orgs so follow 2a)

Step 2a Click on the Drop Down to the right of New and click on New Legacy

Step 3 Add Named Credential Details

Step 3 Create a Custom Label to hold the api key you got from APILAYER (this is only necessary if an api key is required it is for our use case)

Step 4 New Fields I created 2 fields on the Lead Object Phone_Number_Details__c a rich text field to hold the information about the phone number that will get returned in the callout and I also created a checkbox field called Phone_Number_Validated__c that is checked true or false if a phone number has been validated in the service

Step 5 Let’s make a flow – In this example I am using a record-triggered flow that will fire when a lead is created. I set two conditions on Phone to make sure this fires only when there is a value in the Phone field. I also marked it to include an Asynchronous path since we can only make a callout Asynchronously.

On the asynchronous path click on the “+” and then add an action

After clicking on action a modal will pop up and you will want to scroll down to the bottom of the left panel and click on “Create HTTP Callout (Beta)”

Next fill out the details for the HTTP Callout Action you are creating the name is all one word no special characters or spaces, make sure to add a description because you will be able to reuse this in other flows without a need to create a new one so make it easier on other admins, devs and your predecessors so they know what it does, and finally choose the named credential you created in Step 1.

On the next screen we want to give it another label and description along with setting our Method which in the beta is only GET which means we can only retrieve data from an external service. We can also optionally set a URL Path in this case we will use ‘/validate’ this path comes from our api documentation that says this is what we want to do on the service. We are also going to set some Query Parameter Keys this is the data we want to send to our service for our use case we want to send the apikey and the number both of them have a datatype of string we use the names and data types that are from the api documentation; I also made both required otherwise the call will fail. The task is to give an example of what a successful json response will look like once again we get this from our API Documentation. After you paste your example click review and you should see the data structure on the right click done.

Step 6 Configure the new action you created. Give it a name and description like all best practices. In the apikey input I am referencing the label I created in step 3 using the global variable for label and in the number field I am referencing the phone file using the Record Variable from the lead

Step 7 Almost done I created a text template to populate the Phone Details Field I created. In the text template I am referencing the outputs from my service I just created it will create what’s called an Apex Defined Variable I can reference specific pieces of data.

Step 8 Update the Lead Here I am updating the Lead Record that is my Triggering Record updating the Phone Validated and Phone Detail fields.

Step 9 Debug, Validate, Activate, Deploy – Next up debug your flow make sure you set to debug on the asynchronous path and review your debug details and validate it is doing what you expect. Once it’s validated activate your flow and deploy it 🙂