Meet John: A busy Sales Executive with many accounts and leads to manage. He spends a lot of time in Salesforce, and knows first-hand just how frustrating it is when the data’s missing or incorrect. You’ll find no firmer advocate of Salesforce data hygiene than John.
Naturally, he’s pretty happy when the company hires a Salesforce Admin to enforce some quality control principles. But when the rules are rolled out, John’s shocked to discover that he very quickly becomes the problem.
Every time a new lead comes in, Salesforce validation rules require him to fill out a whole host of details that he simply doesn’t have on hand. Before long, ‘Unknown’, ‘TBD’, and other placeholder text become the default setting. In the end, your CRM’s data quality just gets worse – not better.
So, what’s the alternative?
Data Validation in Salesforce: How It Works (And When It Doesn’t)
There’s a good chance you already have a working knowledge of validation rules in Salesforce. Broadly, these are a set of policies that define what information is required in Salesforce, and when:
- Required fields: Working at the page or field level, these force the user to enter a value before saving the record.
- Validation rules: These let you build more complex logic-based requirements – like blocking information from being saved when particular conditions aren’t met.
- Picklist restrictions: By defining picklists, you can force Salesforce users to choose from a list of pre-defined options. This helps keep the data comparable and consistent.
- Record types: This lets you define what fields and layouts are shown to which users, reducing visual noise and the risk of information being entered into the wrong place.
- Salesforce Flow/Process Builder: Like validation rules, these enable more complex conditional logic about what information users can enter into Salesforce, and when. You can also use these to set default values or prompt the user to fill in certain fields in particular scenarios.
Each of these features has a role to play in effective Salesforce data governance. But on their own, they’re far from enough. In truth, they all suffer from the same limitations: Enforcing structure rather than truth. None of these actually answers the more fundamental question: ‘Is this value true, correct, and usable?’
This means, in practice, many key issues that often arise when Salesforce Admins rely on these tools alone:
- No verification: None of these tools can verify whether a value is real – only whether it exists and matches the expected format.
- Emails and addresses: Similarly, they can’t verify the correctness of email and physical addresses. Format matching can only go so far here – users can still input fake values that match the format but aren’t actually real.
- Compliance doesn’t equal truth: Too often, Salesforce users get around validation rules with placeholder text like ‘unknown’, ‘TBD’, or a made-up value. If the info isn’t available at that stage, they have little other choice. This might get around field restrictions – but it introduces bad data into the CRM, which admins and users can have little to no visibility over.
- Unnecessary friction: Too many information requirements at the wrong time can do more harm than good. If the sales rep is in a hurry, or the integration system you’re using doesn’t have the right field mapping, there’s a good chance you’ll end up with garbage values just to unblock the save.
- Can’t clean existing records: All these tools work at the point of save – meaning they have little impact on bad data that’s already in the CRM. A new required field can’t retroactively fix old records.
- No visibility: Using these tools, admins still can’t visualize where placeholder or incorrect data already exists. Even if the rule is there, there’s no way to check whether or not it’s actually working.
These issues aren’t theoretical – incorrect or placeholder information creates crucial issues for the people and systems working with your Salesforce data. That means sales teams don’t have the information they need to communicate effectively with confidence. At the same time, any AI tools or data models you’re training on that data will become less and less effective, as incomplete data increases.
All of these drawbacks prevent you from effectively governing the quality of the data in your CRM. But alone, they’re not the only options available.
A Better Approach to Data Validation
Here’s a fundamental principle to understand about bad data in Salesforce: If you require information that the Salesforce user doesn’t have – no amount of data validation can turn ‘unknown’ into the correct value.
Most of the issues we describe come down to this one straightforward issue: Requiring the wrong information at the wrong time.
But what’s the alternative? The last thing you want is to create a wild west CRM, with every user putting different information, at different stages, in whatever format they choose. This is the antithesis of good data quality in Salesforce.
Luckily, data validation isn’t just a case of on or off. Instead, how you define and enforce these rules can make a huge difference to data quality:
1. Progressive Profiling: Collect the Right Data at the Right Time
A good place to start is to think more strategically about what information you’re requiring and when. It’s helpful to collect data in stages, instead of requiring every field when the record is created. This ‘progressive profiling’ in Salesforce reduces the chance that the user is forced to input information they simply don’t have.
To implement this, you can simply reduce the number of up-front required fields. When a record is created, this might include just the first name, last name, and email. As the prospect progresses through different opportunity stages, you can use Salesforce Flow or page layout rules to define additional requirements. These might include phone number, company size, or industry.
Requiring this information later greatly increases the chance of the Salesforce user actually having it.
2. Tailor Validation Rules to Record Type
Depending on the record type, lifecycle stage, or where the data came from – you could have very different amounts of information available. Therefore, it’s also helpful to ensure data is only required when it makes sense for that particular record.
For example, if a record is being automatically created via a lead-to-record form, you might only collect the user’s email. This would avoid creating too much friction for a potential customer. Otherwise, a lead created by a sales rep could require a name, email address, and company. Then, further details like phone number, industry, and organization size can be collected or clarified later.
3. Allow and Report on Unknown Values
If a Salesforce user genuinely doesn’t have access to information, there’s only so much help a required field can be. Instead, a better approach is to allow ‘unknown’ as a valid option. With the right process, we can make this time-limited and fully auditable.
Ultimately, if you block unknown values, the users will just find unhelpful workarounds. If you allow it without oversight, you’ll end up with a data swamp. Therefore, the best approach is to allow ‘unknown’ fields – but build accountability and governance around them.
To do this, you can add ‘unknown’ as a picklist option for fields like industry, organization size, or lead source. Then, create a report or dashboard that shows when key fields are still unknown. You can also use Salesforce Flow to set up follow-up tasks. With these, you can prompt the account owner to update the information – either after a set period or when the lead moves to the next stage.
4. Build Structured Exception Paths
At this point, we should also consider legitimate edge cases. These are situations like a prospect preferring not to provide a phone number, or if the account doesn’t have a publicly available address. Here, it’s helpful to build a structured process that can flag and monitor the record without forcing the user to input placeholder information.
Ultimately, this helps to keep your data honest and reduces unnecessary friction for Salesforce users.
To do this, you can create a queue or status that records move into when key fields can’t be filled. Then, you can create a Salesforce Flow to assign a follow-up task to either the account owner or the Salesforce Admin. You might also choose to define a ‘data exception reason’ field on the record – giving you oversight over why the information isn’t available.
5. Implement a Data Ownership Model
A data ownership model is a set of rules that decide who owns and fixes data – and when. The idea is to ensure that there is an explicit ‘data steward’ who is in charge of overseeing and governing data in Salesforce. Without ownership, there’s a danger that data quality becomes everybody’s problem but nobody’s job.
This doesn’t need to be the same person all the time. Instead, you might want to put somebody from the sales team in charge of lead data quality – and a Customer Success Manager in charge of contact data. In practice, having a data owner is more important than who it specifically is.
Here’s where to start: First, assign data stewards to particular areas, perhaps splitting up by object or team. Then, define what ‘clean’ means for each object – including which fields must be populated, what formats are expected, and which values are acceptable.
It’s also helpful to create data quality reports (see last section) that track and report on ‘unknown’ fields. You can then assign tasks to data stewards to review these reports and resolve the issues, using Salesforce Flow.
Validate Data in Real-Time With Plauti
The techniques we’ve described in this piece go a long way to resolving the most pervasive data quality issues in Salesforce. Together, they help ensure we’re requiring the right information in the right place. This reduces unnecessary friction for Salesforce users – and means they’re far less likely to submit placeholder information just to get around strict validation rules.
But crucially, none of these solutions can actually check the accuracy of the information being submitted. If an account manager accidentally puts the wrong digit in a phone number – there’s still no way to actually check if the number is valid.
That’s where Plauti comes in. Our tools build upon the principles we’ve discussed in this piece, offering an extra layer of real-time data validation. Here’s what that includes:
- Plauti Verify: This verifies email addresses and phone numbers at the point of entry to check they are accurate and legitimate. It can also do this in batch, so you can identify existing issues in your CRM.
- Plauti Context: Analyze your existing CRM to find broken, missing, and poor-quality data across Salesforce objects and fields. This lets you diagnose data quality in batch, so it’s ready for automation, reporting, and AI.
- Plauti Agentforce: Extend Plauti Verify’s functionality to Agentforce products, ensuring contact details like email and phone number can be validated in real time.
- Plauti Deduplicate: This lets you manage duplicates that arise due to fake, placeholder, or inconsistent data entry. This applies both at the point of data entry and to existing records.
- Plauti Manipulate: Handle bulk data tasks like mass delete, assigning ownership, and creating tasks. This makes it easier to monitor and handle inconsistencies in your data.
Check out our website to find out more about Plauti – or get in touch with our team to get started.
