#http-callout — Public Fediverse posts

Transform Element and HTTP Callout for Random Test Data

When creating apps, it’s crucial to test them thoroughly to ensure they work properly. A key part of testing involves using a large test data set that can cover all the scenarios the code is built to handle. It is better to use random fake data known as mock test data for this stage of development. This process helps find and solve problems before your Salesforce solution is released to the public. Think of it as a rehearsal that helps make the final performance smooth and error-free. By testing with this fake random data, developers can make sure the software can handle different situations and fix any hidden issues. Read this post to learn how you randomize your Salesforce Org data for testing by leveraging a free API that produces random user/contact test data.

After you build and deploy this flow solution, you will be able to set the checkbox fields on contact records for these contacts to be updated with random test data.

How Does It Work

The process works as follows:

1. You set the is_test__c checkbox to true on a single record or multiple records.
2. A record-triggered flow is launched. The flow uses a subflow to execute most of the critical process logic under an async path (the use of a subflow is not required).
3. The subflow calls the free Random Data API using an HTTP Callout. The results are processed using the transform element to assign the relevant values to contact fields. Necessary formula transformations are executed during the process: The two lines of street address coming from the API are concatenated into one field. The contact record is updated, and you will have brand new random name and address field values in your contact records, once the solution executes.

Here is how you set up your flow:

1. Set up your External and Named Credentials
2. Build the HTTP Callout Action
3. Build the Transform Element
4. Finish the flows, debug, and execute

And naturally, test, deploy, and execute your solution.

Let’s dive into these steps:

Set up your External and Named Credentials

Create an External Credential as seen below.

Here is the secret to getting this to work. Your external credential requires a principal to be visible from a permission set, although your API does not need it. I created one and typed “Hello” in it. Don’t ask me why this is needed, because I don’t know. See how I have done it in the screenshot below. I thank @joshdayment for his tip on this step.

Create a Named Credential by entering the Random API URL. This configuration will be linked to the external credential you have created in the previous step. The URL:

https://random-data-api.com/api/v2/users

Create a permission set and assign your user this permission set. The permission set needs the “RandomDataAPIExternalCredential – Hello” added under the External Credential Principal Access section.

Build the HTTP Callout Action

You will build a flow solution that triggers an HTTP Callout. I used a subflow that I called from a record-triggered async path, but the use of subfow is not required. You can build everything in the record-triggered flow.

Create an autolaunched flow that will serve as the subflow. Your subflow needs to accept a contact record variable as input. It will pass the contact record variable as output once it is done.

Go to add action element and click on the HTTP Callout button on the left bottom of that modal window. Point your HTTP Callout to the Named Credential you have created. You will use the get method. Configure two parameters for input into the callout: Response type and number of users we want the API to generate the data for. Have the configuration process fetch the sample data and automatically configure the response format. You can hardcode the parameters into the HTTP callout as “json” and “1” respectively. We will ask for one contact/user data at a time. The use of a variable as seen in the picture below is not necessary.

Build the transform element. Map the response to the contact record variable fields.

I used two formulas in my mapping. One that concatenates the two street address values from the API into the single Street Address field, and another one that combines many interesting fields to update the description field of the contact record. Here is the formula for the first item:

{!Random_User_Data_API_Action.2XX.address.streetx5fname}&" "&{!Random_User_Data_API_Action.2XX.address.streetx5faddress}

Build as many formulas as necessary. Create custom fields for the API data you find interesting, and want to capture in separate fields.

Now add an assignment as seen below.

Finish the flows, debug, and execute

Your record-triggered flow will look as seen in the screenshots below (click on the image to see a bigger version).

Here are a few points to remember:

• Your HTTP callout needs to be under an async path.
• When the record variable for the contact comes back from the subflow, the Id value is wiped out. I added an assignment to add the $Record.Id value back into the record variable. The Id is required for the update element.
• My solution does not change the contact field values the transform element does not have mappings for. You can set yours up to wipe out all other field values.

Here are a few additional screenshots from the debug run that show the results (click on the image to see a bigger version). By using this flow you can test your Salesforce solution by resetting your contact record field values to random name and address values as many times as you need.

Conclusion

Wrapping up, this post has walked you through the essential steps and innovative strategies for effectively testing your Salesforce applications using mock test data. By leveraging the free Random Data API to inject random user and contact data into your Salesforce Org, we’ve demonstrated a method that not only enhances testing accuracy but also prepares your Salesforce solutions for real-world scenarios. Remember, thorough testing is the cornerstone of deploying error-free and reliable applications. As you embark on this journey, don’t hesitate to experiment, learn, and apply these practices to ensure your Salesforce solutions stand the test of user expectations and system demands. You can watch the solution demo video on the Salesforce Break YouTube channel to see the solution in action. 👇

https://youtu.be/WzeYfXVubys?si=zMxcl8_goyi71oHP

Enjoy.

Read more on HTTP Callouts:

HTTP Callout Get Method

HTTP Callout Post Method

Shorten URLs using the HTTP Callout Post Method

Note: Transform element functionality is currently in beta (February 18, 2024).

#API #Data #HowTo #HTTPCallout #Integration #Mock #RandomData #Salesforce #Test #TestData #Tips #Video

HTTP Callout in Salesforce Summer 23 – POST – 3/3

Welcome to the final installment of our three-part series on configuring Salesforce flows within a community site. In this post, we focus on a flow that utilizes HTTP Callout to fetch and display Opportunity details using a record ID. This setup ensures streamlined access to essential data through a user-friendly interface, all running in the System context without sharing for enhanced security.

Join us as we walk you through the integration of this flow into your digital experience, emphasizing the role of URL parameter handling and the utilization of HTTP Callout for secure data retrieval. We’ll also demonstrate how to automate email notifications with dynamic links. We value your feedback—please let us know if you need more detailed information on any of the steps!

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 the system builds a decision to handle cases where the recordId input is missing or invalid.

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: The system has populated your long URL and short URL, and sent the email 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.

Explore related content:

Create HTTP Callout – POST 1/3

Create HTTP Callout – POST 2/3

Create HTTP Callout – GET

#API #Automation #HTTPCallout #Release #Salesforce #Summer23

HTTP Callout in Salesforce Summer 23 – POST – 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.

The introduction of HTTP Callout in Salesforce Flow during Spring ’23 generated a lot of excitement, but one key limitation was the absence of the POST method. With Summer ’23, Salesforce not only moved the GET method to General Availability (GA) but also introduced the POST method in Beta, addressing a major user request.

To demonstrate the real-world application of this new functionality, a use case was chosen based on a client requirement: shortening long URLs before sending them via email or SMS. Since SMS does not support rich text formatting, a short URL is essential to improve readability. Bit.ly’s API, which supports a POST request to generate short links, was used for this purpose.

Please continue to the second post by clicking here.

Explore related content:

Create HTTP Callout – POST 2/3

Create HTTP Callout – POST 3/3

Create HTTP Callout – GET

#API #Automation #HTTPCallout #Release #Salesforce #Summer23