Check for Blank Fields
Using a Flexible Invocable Action to Easily Check Field Population
Created by Elliot Hebert, Application Architect at RafterOne
This Post was most recently updated on: 8/13/24
Current Version: 1.0
Data is the lifeblood of Salesforce, powering informed decisions and insights. However, maintaining data quality can be a significant challenge. Sales reps and service agents must accurately input critical information, but often require guidance and enforcement.
Salesforce admins work tirelessly to ensure data integrity, but complex business rules can make managing validation rules a daunting task.
While validation rules are valuable for simple requirements, intricate business logic can turn them into a maintenance nightmare. Let’s explore more effective and manageable approaches to data quality.
As we know, Salesforce is always changing, and always providing new, sleek alternatives. Today we are going to showcase using the new Custom Error element, and a simple Invocable Action, and how they can combine to make an admin friendly approach to ensuring field validation doesn’t become a headache.
Our Scenario…
I have a new requirement as a Salesforce administrator to check that certain fields are populated on a Lead before it can advance to the next Status. The company is in the early stages of adoption and the list of required fields may change at any given time. Therefore, I need a flexible, modular approach that can help me make changes on the fly if required.
As an admin, I want to ensure I have clear validation messages to users, and in order to do that, I would have to write one validation rule per field so that users can see each field validation individually. Well what if I had 10 required fields? I would have to write 10 validation rules. While I could write a single validation rule that captures all 10 fields, the error message would be inaccurate if the rule was partially met.
But there is an easier way…
The Flow
I want to be able to check all 10 fields, and avoid writing 10 validation rules. We can easily streamline this by using Flow + Invocable Actions.
The business requirement is that I ensure all of these fields are populated before I move my Lead to the Working – Contacted Status.
- I use my Entry Criteria to run the flow when the Status field is Working – Contacted
- I run my Invocable Action to check against field population requirements
- I display a Custom Error in a toast message to the User, who cannot proceed until the requirements are met
The Invocable Action
- First, you choose the Object you are interested in looking at
- You enter a comma separate listed of field API Names that you want to check for population
- You provide a record variable of the record you are checking
In this example, I am checking field population on the Lead object, and I am checking the following fields for population:
- Industry
- Rating
- Fax
- Title
- Phone
- Website
- Company
- Annual Revenue
The Invocable Action has an Output Variable that gives the Field Names is a user friendly, readable list that can be dynamically used in Flow. In our scenario, we are using that to feed into our Custom Error message.
See It In Action
On my Lead, I try to move to the Working – Contacted Status, and I see the following:
I was able to display ALL required fields, without writing 10 validation rules. Now, our Rep populates a few more of the required fields, such as Industry and Website and tries again.
You’ll notice the list of required fields automatically updates and shows a new list of missing fields with values.
Restrictions
Attributes
| Attribute | Type | Notes |
| INPUT | ||
| fieldApiNames | Comma separated text of field API names | List of field API names to check |
| record | SObject | Single record |
| OUTPUT | ||
| blankFieldsListString | Comma separated text of field API names | List of field API names where the record has no value for the field |
Notes
Installation
Production or Developer Version 1.0
Sandbox Version 1.0
Source
Release Notes
8/1/24 – Elliot Hebert – v1.0
Initial Release