I never thought I’d say this. But I guess we need a formula builder inside flow decisions.
I recently got involved with an extensive migration-to-flow project.
Many workflow rules and processes needed to be combined into one single flow. 🚧
When you have complicated criteria in a workflow rule, you can use the formula builder in the flow start element to rebuild the same formula. You need to change field references, of course, but the new formula looks more or less the same as the old formula.
The difficulty comes when you combine a few of these workflow rules into one flow. Now you need to write combined formulas.
And if your cases are not mutually exclusive, you need to build at least two-level decision elements to check whether the original email alert or field update has to be invoked.
I understand that this exercise is a challenging task for many. 😓
I have especially seen confusion around negative statements like “does not equal to”. Once you combine these with AND and OR, you end up with very challenging formulas. 🔥
This is a broad topic that I would like to discuss with you in a web meeting event. But before I give you more information on that, let me give you one tip about the AND/OR logic 💡…
When you want to select all Opportunities that are not in Closed-Won or Closed-Lost stage where the NextStep is not blank this is not the formula or criteria you are looking for ❌:
This is not correct because the second part of this formula that starts with OR will always yield true.
What you are looking for is this ✅:
Here the second part of the formula will give you all opportunities that don’t have the values Closed-Won or Closed-Lost in the StageName field.
I have specific recommendations that will make your life easier when tackling a project like this. I am sure you have many tips as well.
Winter 23 comes with several flow usability improvements:
The toolbox left panel is turned off by default in auto-layout to make more screen space.
Element search on the Add Element screen supports text search for element names and subflows & actions.
Salesforce is reporting now that the canvas is bigger with more area to play with.
Screen configuration screen in screen flows takes up more screen space to allow more visibility for columns and component previews.
Update related records in Record-Triggered Flows got easier: A dedicated radio choice has been added.
Let me show a few of these with supporting images: add element dialogue now supports text entry. Elements, subflows, and actions are returned and displayed on the screen in response to the text search.
When you added a screen element in your flow builder, the configuration screen took a smaller portion of the screen, which made working with the screen design difficult. Now you get a bigger configurator window.
Updating records related to the records that triggered your flow got more guidance with this dedicated radio choice in the Update Records element.
Winter 23 brings you a “check syntax” button on the formula resource configuration screen. Previously we had this functionality only for the collection filter and the start element screens. What did you need to do before this release when debugging your formula resources?
You created formula resource(s) and closed out the screen for the formula resource configurator.
You saved the flow.
You received one or more error messages. These may be related to one or more formula resources.
You went back into the formula resource(s).
You made corrections and closed out the formula resource configurator.
You saved the flow again.
You rinsed and repeated. 😫
Now you will do this:
Build your formula on the formula resource configurator screen.
Click on the “check syntax” button on the same screen.
Review the error message and correct the error. Click on the same button and repeat. ✅
Needless to say, this will bring significant improvement in efficiency.
Now that I have received this functionality, I will ask for one more thing. I know I am getting spoiled:
A formula builder and syntax check in decision elements.
I did not know I needed this. But wouldn’t it be awesome?
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.