We enriched about 600 contacts in Salesforce over the course of a month. The tool worked. Emails came back, phone numbers filled in, titles got updated. But when we pulled a pipeline report three weeks later, we noticed something: 40+ contacts still had no email. Another 30 had job titles from companies the person had left months ago. And a handful of newly enriched leads were sitting unassigned because nobody had routed them after the data landed.
The enrichment tool did its job. Everything around it didn't.
That's the part people don't think about. Enrichment fills fields, but it doesn't handle the gaps it leaves behind, the data that goes stale after it's written, or the downstream actions that should fire once new data arrives. For that, you need something watching the records after enrichment runs.
We built three Salesforce Flows to solve this. No code. Drag-and-drop in Flow Builder. Each one took under 30 minutes to set up, and together they turned our enrichment tool from "nice to have" into something that actually changed how the team worked.
Flow 1: create a task when enrichment comes back empty
Enrichment tools don't find everything. Some contacts have no email in any database. Some have phone numbers that are genuinely unlisted. When that happens, the record just sits there with a blank field and nobody notices.
We built a Record-Triggered Flow on the Contact object that fires after a record is updated. The entry condition checks two things: the Last Modified Date changed (meaning something just touched the record) and the Email field is still blank.
When both conditions are true, the Flow creates a task assigned to the contact's owner. The subject line reads: "Manual research needed - no email found for [Contact Name]." The due date is set to three business days out.
Here's the setup:
Object: Contact
Trigger: A record is created or updated
Entry conditions: Email is blank AND Last Modified Date equals today
Optimized for: Actions and Related Records (after-save)
Action: Create a Task - assign to record owner, set subject, set due date to {!$Flow.CurrentDate} + 3
One thing we got wrong the first time: we didn't filter out records that were being updated by the enrichment tool's integration user. So every time the tool wrote a phone number but left email blank, the Flow fired. Then when a rep manually updated the record later, the Flow fired again. We added a condition to check that the Last Modified By user isn't the integration user, so the task only creates once after the enrichment pass is done. If you're running a different enrichment tool, check which user it writes records as and add that filter.
This won't scale perfectly for every team. If you enrich 5,000 contacts in a batch, you'll get 5,000 tasks for the ones missing emails. That's overwhelming. For bulk enrichment runs, a better approach is a Salesforce report filtered to Email = blank, run after the batch completes, and then assign follow-up in batches. The Record-Triggered Flow works best for ongoing, incremental enrichment where contacts get updated one at a time or in small groups.
Flow 2: flag stale records for re-verification
Enrichment data has a shelf life. People change jobs. Companies get acquired. Phone numbers get reassigned. A contact that was accurate in January might be completely wrong by July.
We built a Schedule-Triggered Flow that runs every Monday morning. It queries all Contact records where the Last Modified Date is older than 90 days. For each record, the Flow updates a custom checkbox field called "Needs Re-Verification" to true.
Here's the setup:
Type: Schedule-Triggered Flow
Schedule: Every Monday at 7:00 AM
Object: Contact
Filter: Last Modified Date is less than TODAY - 90
Action: Update Record - set Needs_Re_Verification__c to true
You'll need to create the custom checkbox field first. Go to Setup, then Object Manager, then Contact, then Fields & Relationships, and create a new Checkbox field called "Needs Re-Verification" with a default value of unchecked.
Once the field exists and the Flow is running, you can do two things with it. First, build a list view in Salesforce that filters to Needs Re-Verification = true. This gives reps a running punch list of records to check. Second, add a condition to any campaign or sequence that excludes contacts where Needs Re-Verification = true. That keeps stale data out of your outreach.
One limitation: Last Modified Date tracks any change to the record, not just enrichment changes. If a rep updates a note field, the clock resets. For more precision, you could create a custom date field called Last Enriched Date and have your enrichment tool update it every time it writes data. Then filter the Flow on that field instead of Last Modified Date. We didn't do this initially because it requires your enrichment tool to support custom field mapping, and not all of them do. The Last Modified Date approach is a good enough starting point.
The 90-day threshold works for most B2B sales teams. If you sell into fast-moving industries like tech startups, consider 60 days. If your market is enterprise with low turnover, 120 days is probably fine. Pick a number, run it for a month, and see how many records get flagged. Adjust from there.
Flow 3: route leads based on enriched data
This is the one that had the biggest impact for us.
Before this Flow, our lead routing ran on whatever data was in the form submission. Someone fills out a form, enters their company name, maybe picks an industry from a dropdown. That's what the routing logic used. Problem is, form data is unreliable. People misspell company names. They pick "Other" for industry. They leave fields blank.
After enrichment, those same leads have accurate industry, employee count, and company information pulled from external databases. But our routing had already fired on the bad form data, so the enriched fields were just sitting there unused.
We rebuilt routing as a Record-Triggered Flow on the Lead object that fires after the record is updated (not just created). The entry condition checks that the Industry field is not blank and has changed since the last save. This means it fires after enrichment populates the field, not when the lead first comes in with incomplete form data.
Here's the setup:
Object: Lead
Trigger: A record is updated
Entry conditions: Industry is not blank AND Industry is changed (using the isChanged operator)
Optimized for: Actions and Related Records (after-save)
The Flow then uses Decision elements to route:
Decision 1: If Industry = "Healthcare" or "Pharmaceuticals," assign Owner to the healthcare rep
Decision 2: If Employee Count is greater than 500, assign Owner to the enterprise team queue
Decision 3: If State = "CA" or "NY" or "TX," assign Owner to the relevant territory rep
Default outcome: Assign Owner to the general inbound queue
The order of the Decision elements matters. We put industry first because our healthcare vertical has a specialized team that should always get healthcare leads regardless of company size. Employee count comes second because enterprise deals need different handling. Geography is the fallback.
One thing to watch: if your enrichment tool updates Industry and Employee Count in the same write, the Flow fires once with all the new data available. If the tool updates them in separate writes (some tools do this), the Flow fires twice and the lead might get reassigned mid-routing. Test this with your specific tool by enriching a test lead and watching the Flow debug log to see how many times it triggers.
This Flow replaced a set of Lead Assignment Rules we'd been using. Assignment Rules work fine for routing on form data at creation, but they don't re-fire when fields are updated later. Since enrichment writes data after the lead exists, Assignment Rules miss it entirely. A Record-Triggered Flow on update was the only native way to handle this without code.
What we didn't automate
Flows have limits. They're great for if-this-then-that logic on individual records, but they're not a replacement for a dedicated data quality platform if you have 50,000+ records and complex matching rules.
We tried building a Flow that would auto-merge duplicate contacts created by enrichment. It worked in testing but caused problems in production because the merge logic couldn't handle edge cases where two records had conflicting data in the same field. We ended up handling deduplication manually with Salesforce's built-in duplicate management and a weekly review.
We also considered building a Flow that would automatically re-run enrichment on flagged records. But that requires calling an external API from a Flow, which means either an Apex invocable action or a third-party integration. It's doable but it's not no-code anymore. For now, re-verification is a manual process triggered by the checkbox from Flow 2.
The setup takes an afternoon
All three Flows together took us about 90 minutes to build and test. The custom fields (Needs Re-Verification checkbox, optionally Last Enriched Date) take another 10 minutes. Testing takes the longest because you want to trigger each Flow with real data and watch it execute in the debug log before you activate it.
If you're using any Salesforce-connected enrichment tool, whether that's Apollo, Lusha, ZoomInfo, Clearbit, or something else, these Flows work the same way. They don't care which tool fills the fields. They only care what the fields look like after the tool is done.
If you're on Salesforce and want to try this with a tool that connects directly into your CRM, ShareCo SalesSync enriches contacts from LinkedIn and writes straight to Salesforce fields. The free tier gives you 40 saves a month, which is enough to test all three Flows on real data. You can grab it from the Chrome Web Store.