Salesforce Sidekick

Have you ever wanted to use a validation rule in your Flow to make sure Users are correctly entering the data?  If you’re like me, you struggle writing them often times because you hardly use them!  They’re essentially the opposite of everything you’ve been taught with formulas, and sometimes it takes a minute for you to mentally step into “validation mode” to write it.  Well, this gets even more complicated when it comes to Flow!  Flow lets you put some pretty awesome Validation Rules into place, but there are definitely some problems with it.

So, before we bash Validation Rules in Flow, lets discuss a few of the great things that you can do!

Now, lets setup a validation rule to check the Account Type to see if its a Customer.  If our Account Type = Customer, we want to require the User to input a Subject.  Notice, we are able to grab a Variable that is on another Object (different from the Case we are about to create here), and use it in our Validation Rule.  Also, look how my rule is placed on the Description and not the Subject, I’ll explain this in just a second!

As you see in the above screenshot, you can literarily call on anything in your Flow!  This means, you can call on any Variable, Input, Choice, SObject Variable, etc.  You can reference just one Object like I have above, or you could get crazy and reference some additional Screen Inputs and maybe the Maintenance End Date of your Client to determine if your Support Agent is even allowed to create the new Case.  How awesome is that!?! With that in mind, lets discuss why so many people can get upset with it!

The biggest issue with Salesforce Flow Validation Rules is that you’re unable to validate on an field being blank.  If we wanted to require a field to be filled out for certain types of records, but not require it for others, you are going to run into some issues!  The reason is, validation rules in Flow ONLY run when a value is placed into the field.  What types of workarounds are available if we don’t want to make the field always required?  Lets take a look!

The first and most preferable way we can solve this is to be using a validation rule on another field.  This means, if you have a required field (or one you know will be filled out), you can put your Validation Rule on that field. When the User attempts to hit “Next” they will be prompted with your Error Message.  This is what we did in my earlier screenshot.  We know that Description is a required field, so we placed a Validation Rule on Description instead of the Subject.  We’re doing the same thing below by placing it on a field we know will always be entered.  Keep in mind, this Error Message needs to be written so the User knows what is wrong, since the message won’t actually display on the ’empty’ field!

The second way requires some additional screen elements, which is why it isn’t as preferable (unless your Flow is very small).  So, in this example we want to create a Decision element that will act as our routing.  This gives us some ‘free will’ to either run this before or after the screen element.  If we already have the ‘value’ that we are validating, such as the Account Record Type, then we actually do our Decision element before the Screen.

If this is something that is decided during or after the Screen, then we will need put the decision element after the Screen.  This Decision element will send us to an alternative Screen Element to prompt them for a value.  In this example, if the User forgot the address on the original “New Account” element, then we would send them to the “Require Address” screen element to fill it out.

A second option for something decided during or after the Screen, is to use an Assignment element and Decision to update the original Screen with your own custom validation error.  This is one is my favorite option of the two, because it is the most simple.  However, it does mess with your potential layout of the error message and fields, so that is why I am presenting you both options.

If you notice in the examples in our first example of the second scenario, we are using an Assignment element to assign the screen input to be a variable.  This enables me to use multiple ‘paths’ that use only one Record Create.  This wouldn’t be possible if I was referencing the Screen Input value.  But, with our second example in the second scenario we are able to avoid the need for this altogether which simplifies our Flow, and is the recommended way of the two.

RECAP:  Validation Rules in Flows give you quite a lot of power, as you can reference even other Objects really easily.  However, there are a few shortcomings that you’ll find.  Sometimes, this means that you’re going to have to add some additional elements to your Flow to accomplish something really basic.  There’s typically a way to solve most validation issues, but you have to get creative… so don’t give up!