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.
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 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:
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.
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 🙂
Step 10 Take a deep breath exhale, pat yourself on the back, put on your superhero cape, and enjoy your drink of choice
Views and opinions in this article are my own and do not represent that of Salesforce
In this video, I went through all the new Winter 23 release features and answered questions. I did not get the time to dive into the testing feature that is going GA. Stay tuned for another video on flow testing.
Let’s get started with the Winter 23 Flow enhancements, shall we? Who doesn’t like to save time and effort?
One of the biggest improvements is the formula resource editor with the instant syntax check button.
This functionality first came for the start element and the collection filter in the previous releases. Now we get the same editor across the board in the flow builder.
No more writing a formula, saving the flow, and crossing your fingers hoping it won’t yield an error message.
You can check for errors as you build your formula on the same screen using the Syntax Check button.
One disclaimer is that I saw some inconsistent behavior in my preview Dev Org:
Some of the collection filter formulas I built that I thought should pass, did not pass the syntax check. But we still have time until the release. I am sure it will be ready by then.
Now content announcements:
I am super excited that my session proposal has been accepted for Florida Dreamin’ 2022. I will be presenting there for the third year in a row. My session is titled: “Flow Design & Mapping: From Idea to the Flow Canvas“. It will be super interesting, I promise you. Come and see it: Register for the event here.
How cool are the brand new start element formulas?
One of the best use cases for it is the Record Type criteria. You can now check for the RecordType.DeveloperName or the RecordType.Name in your start element. This was not possible before. You either had to hardcode the RecordType.Id or defer the criteria to a decision element, making the flow less efficient.
What else can we do with start element formulas?
When you want to trigger your flow in case the triggering object record is created or updated, and you want to build sophisticated criteria, then the formula entry conditions are ideal for this purpose.
A popular use case is the auto-naming of records when a new record is created. For example, you can append the Industry picklist value to the Account name using a before-save flow.
Here is the formula resource that does that:
The difficulty is when you want to trigger such flow on create and update. If you don’t build your flow carefully, you will append the same thing to the name multiple times based on multiple updates. You will need to check whether the auto-name logic ran before if you want to avoid this outcome.
Here is the start element formula that ensures that:
I recommend you go and play with this functionality yourself if you haven’t already. You will like it. It is super powerful.
This is the only area where we have a function, a logical operator picker, and a syntax check button within flow.
If you have comments on this topic, please join the discussion on Twitter or LinkedIn.
How powerful are the collection sort and collection filter elements? How should you use them?
I experimented with collection filter and collection sort elements to see how far I can go using only one get element. In other words, I wanted my flow only to use up one SOQL against the governor limits.
I started with a get element that returns all the cases that have both account and contact assignments. I was able to extract the following information with only one get element:
Most Recently Modified Case
Oldest Modified Case
Oldest Modified Case Account Name
Number of Cases by this Account
Most Recently Closed Date for this Account
Contact Id on this Case
Number of Cases for this Contact
Oldest Closed Date for this Contact on this Case
Please see the image for the results.
How many elements did I use? Did I have to loop?
Here are the answers:
Your get element gives you sorting functionality. Use it.
You have to loop to get the min and max values, such as the oldest and most recent, sorted by Date and Time. But you need to loop only for one iteration. So you can exit after you assign the first record to a variable.
Your loop can use the existing sort or the reverse sort. Use this functionality.
Initially, I used a counter variable to exit the loop, but this was unnecessary. You need to exit the loop regardless after the first iteration. Insert a decision and connect both branches to the next element outside the loop.
You can get a count of records by using an assignment element with the operator “equals count”.
I experimented with the formula criteria inside the collection filter element without much luck. I think this functionality does not allow for filters with variable values on the right side of the equation. “ContactId on the current record = ContactIdVariable” formula did not work.
What do you think? Can these elements save you lengthy loops and executed elements?
How many elements, excluding the start or the end element, did I use to extract this information.
This is an exciting week for all of us. The Release Readiness live webinars are here.
I was reading the Release Notes for Summer 22 this past weekend and I was wondering whether I can use the brand new Slack invocable actions in my Salesforce flows already. Salesforce announced the new actions are in beta, and they will be released sometime in June. It turns out I can already use them. I don’t even need a Preview Org or Summer 22 Sandbox for it. The steps required took some time to discover, but the whole thing is fairly simple to set up.
I am posting a step-by-step guide here so that you can dive directly into it. Try it now without wasting any time. Here are the 6 steps you need to take to post to Slack from Flow:
1. Go to “Setup” and “Enable Slack for Salesforce”. Review and agree to the Pilot terms if you want to proceed.
2. Create and assign a permission set to the user who will post on Slack and use the integration. The permission set will have “Connect Salesforce with Slack” system permission activated.
3. Now go over to your Slack Workspace. You can use a free Workspace, but if you have used all your permitted 10 App limit, you will need to remove an App. On the upper left side click on “More”, then “Apps”. On the screen you see in the middle, click on “App Directory”. Find “Sales Cloud for Slack”.
4. Go to the App page. Click on “Add to Slack”. This will take you to a web page that is super confusing. Find “Add Sales Cloud For Slack App”. Click on the link. Give the necessary permissions. (Update: I received feedback that the Sales Cloud Slack app did not work for some folks. If this is your experience try one of the other apps on the same page. I tested the Salesforce Digital HQ app as well, and this app worked for me.)
5. Now go to any public channel on Slack. Click/tap on the channel header where you see the title. Scroll all the way down and get the channel ID as seen below.
6. Go to Salesforce and build a simple Autolaunched Flow with one single element. You will need to add the invocable action “Send Slack Message (Beta)”. Configure it as seen below. Include the Slack Channel ID. Run it. Voila!
Next week, I will continue my preview with the new screen flow functionality.