The Winter ’24 seasonal release is almost here! The first release weekend for the Winter ’24 release is due to take kick off on 1 September (shortly before Dreamforce), with the remaining two release weekends taking place in early to mid October. This means that Preview Orgs and Sandboxes are going through the process of being refreshed, Preview Orgs have already been refreshed and Sandboxes are due to be refreshed on 25 August. Because of this, over the next number of weeks you will see blogs like Salesforce Ben and Salesforce Admins covering the upcoming release, as well as the streaming of Release Readiness Live.
Back in the Summer ’23 release period, I wrote a couple of posts covering specific items that were really cool that the community voted on being covered here on this blog. In this release cycle, I will be looking to do something similar to that for Winter ’24. At the time of writing, the release notes have not gone live (they are due to be published on 16 August), so I haven’t had chance to read the notes for this release myself as of yet. Once that happens I will put out another poll to cover the updates that I will be able to cover and take it to the community to vote on what updates get their own individually focused blog. But for now, I have one item in the upcoming release that I think is such a significant change that I won’t be including it in a poll, I’m just going to write about it.
So in this post, we are going to focus on one of the new elements coming to Flow in this release, that being Custom Error Messages. What we’ll cover in this post is what the element is, what it potentially says about the future direction of Salesforce, and my initial reactions of how it should be used by Salesforce professionals going forward. Like with all my other posts, I’d love to hear your thoughts about this, so please do feel free to post a comment below or reply to my social media posts sharing this content.
With that being said, let’s dive in to Custom Error Messages in Flow Builder:
What Are Custom Error Messages in Flow?
Custom Error Messages are essentially Flows version of Validation Rules. This new element in Flow is available in Record-Triggered Flows and allows you to configure custom error messages that can be totally dynamic and show error messages when you attempt to save a record. In terms of how they look in the Salesforce UI, these messages display exactly like Validation Rule error messages.
So the explanation of Custom Error Messages is rather simple, but what do they actually look like to configure? Let’s have a look.
The screenshot displayed for this section shows the new Custom Error Message element fully configured. You will see that you have a text component that can be used to compile the error message. With the inclusion of the Resource Picker, you will be able to include variables within the Flow..
One thing to note is that there are two different options for where to display the error message when it surfaces.
These two locations are as follows:
- In a window on a record page.
- As an inline error on a field.
In theory the first option should display the error message as a popup message and the second as a message underneath the field set in the Element. However, in my testing of the tool both messages are displayed as popup messages and both prevent saving of the record that you are trying to save.
After adding a Custom Error Message Element to a Record-Triggered Flow, you will be able to see it in action once you activate the Flow. As you will see from the screenshot provided, when I create a new Opportunity and don’t include an amount, the error message will be flagged saying that the record can’t be saved without an amount added. In the example I set up for this post, the Flow that I built showed the error message based on the entry conditions of the Flow, with those entry conditions being that the Amount field was NULL. So with that being the case, the question moving forward should be what is the best practice for using this Element.
How Should We Implement The Custom Error Message Element Going Forward?
At the beginning of my post I said I would share reactions of how this new element should be used going forward, but truthfully I’m in two minds about it. On one hand we have to consider that this element is essentially the same thing as a validation rule. On the other hand, we also should be considering whether or not this new element can act as a tool to explain those totally awful error messages we often get from Flow. You know the ones where you sometime need a rosetta stone to translate them, those ones. Personally for me as a Flownatic, this is where I would be very interested in hearing from the Trailblazer Community. So let me hear your thoughts about how this new element should be used in the comments below or online via Social Media. Talk to me.
At the time of writing, there are two approaches I can see as being the best options when it comes to using this new element. The first is to include it in the Flows we build as a means of circumventing those horrible error messages that I previously mentioned. How exactly that works still needs some thought in my book with this being so new, but let’s say for example you want to re-assign the Owner of an Opportunity record. Normally you would want to ensure that the User you are re-assigning the Opportunity to is Active, so with this kind of methodology you could include a Get Request on the User record, add a Decision Element to check if the User has an IsActive value of TRUE, you would then flag the Custom Error Message if the value of IsActive is FALSE. This approach will actually begin to prevent Flows from completing in the UI front and then send email messages, instead we will begin to see users be able to remain in the edit screen of a record and not have to go back to editing the recording after resolving the error/s.
The second option that I can see as being best in my mind is to pivot towards including validation in your Flows at various points. Personally I’m an advocate for creating Flows based on business processes and using Autolaunched Flows to break the automation down into smaller more manageable chunks. Right now we can’t use this element in Autolaunched Flows, but we could begin to include this new element with the Flows we build to again prevent closure of the record. How this model would work is that you would include Decision Elements and then include the Custom Error Message Element based on the Outcome of that Decision. From my perspective, I would probably use the Default Outcome as the one that we attach the Custom Error Message to. In terms of an example, let’s again stick with an Opportunity record. Let’s say you want to ensure that all Opportunities that are set to the stage of Closed Won to have an Amount set in the Amount field. In this scenario you could a Decision Element where the Outcome would check if the Stage was Closed Won and the Amount was not NULL. From there you would allow the user to continue if the conditions were met and display the error message if not … just as you would with a validation rule. The benefit of this approach would be relatively simply, it would be that you wouldn’t have to go to various locations to handle your validations. It could all be done within a single Flow, making it much easier to make tweaks, corrections, or updates to the validation going forward. Plus, you could make it dynamic … there’s just something appealing about being able to make these error messages more user friendly.
What Does This Element Say About the Direction of Things Going Forward?
OK … so to close out today’s post we’re going to put our tin-foil hats on and ask, what does this new element say about where Salesforce is taking Flow in the future? Now, hands on the table, I do think that Flow will eventually be used to eventually replace some of the legacy functionality in Salesforce such as Approval Processes and Email Alerts. This addition does suggest to me that Validation Rules may be added to that list of legacy functionality that Flow will eventually replace. Honestly, at the time of writing I don’t think that is the case, but I do think this new element is something that Salesforce will begin to push as a best practice, particularly in cases of Error Handling and validation tied to the Flows that you build. I don’t think we’ll see a call to replace all of our Validation Rules with Flows just yet, although based on what this new element does, I could it see it happening down the line. This may sound like a bit of a nothing-burger, but the ability to customise Error Messages in Flows has been in HUGE demand for a very long time. Right now I don’t think this satisfies every use case (for example the selection of inactive picklist values), but I do see it as being a major step in the right direction. I would love to be able to use this element to say to User that they can’t save a record because they don’t have access to it’s parent record as an example. I think this new element has a lot of legs on it and I am really excited to see the use cases Trailblazers come up with on how to really make this a valuable resource in their Flow arsenal.
Before I close, I think it is worth highlighting that I would really love to see this element be added to Autolaunched Flows. I can see a tremendous value in being able to create singular Error Handling Flows that use this element one for inline error messages and one for popups, with the parameters for the record tied to the error and the message itself being passed into the Flow via input variables. I realise that would require some tweaks to be made to the element, such as the ability to set the record the message is displayed against and the field to display the message under in the case of inline error messages. That being said, I can totally see the value of adding this functionality to Autolaunched Flows to allow us to create Reusable Error Handling Flows.
Closing Comments
So that’s the new Custom Error Message element. Pretty cool right? I certainly think it is. But what about you? I’d love to hear your comments about it in the comments below or online via social media. So let me know what you think. What do you see as being the best practices for using this new element? How will you use it when it goes live in Winter ’24. Tell me what you think.
