One of our users enriched 100 contacts on a Monday. Phone numbers, emails, titles, industry, company size. The tool ran, the fields filled in, and the admin who set it up confirmed everything looked correct from their account.
On Tuesday, two SDRs reported that the enriched fields were missing. They could see the Contact record. They could see name, account, and owner. But the Mobile Phone field was blank. The Industry field wasn't on the page. They refreshed. They logged out and back in. Nothing changed.
The data was there. We could see it in the API. The admin could see it on their screen. The reps couldn't.
It took us about 45 minutes to figure out what happened, and the fix took about 5 minutes once we understood the problem. The issue wasn't the enrichment tool. It was Salesforce permissions.
Two layers of access control that work against each other
Salesforce controls data visibility at three levels: object, field, and record. For enrichment problems, you almost always hit the first two.
Object-level permissions determine whether a user can access the Contact object at all. These are the CRUD permissions: Create, Read, Edit, Delete. If a rep has Read access on Contacts, they can open contact records. This is the layer most admins get right because it's obvious when it breaks. If a rep can't see the Contact tab, someone notices immediately.
Field-level security is the second layer, and this is where enrichment data disappears. Field-level security controls whether a user can see a specific field on an object they already have access to. You can give a rep full Read and Edit access to the Contact object but block them from seeing the Mobile Phone field, the Personal Email field, or any custom field your enrichment tool writes to.
The critical thing to understand: field-level security overrides page layout settings. If a field is on the page layout but the user's profile or permission sets don't grant field-level visibility, the field is invisible. It won't show an error. It won't show a blank field with a lock icon. The field simply doesn't exist from that user's perspective.
This is exactly what happened to us. Our enrichment tool wrote data to the Mobile Phone field and a custom field called LinkedIn_URL__c. The admin's profile had visibility on both fields. The SDR profile didn't.
Why this happens more often with enrichment tools
When you create a new custom field in Salesforce, you get a screen that asks you to set field-level security during creation. Most admins check the boxes for the relevant profiles right then. The field gets created, gets added to the page layout, and everyone can see it. No problems.
Enrichment tools don't follow that workflow. They typically write to existing standard fields (Email, Phone, Mobile Phone, Title) and sometimes to custom fields the tool creates during installation. The custom fields created by AppExchange packages or API integrations don't always inherit the same field-level security settings as fields you create manually. Some packages set visibility for the System Administrator profile only. Some set it for all profiles. There's no standard.
So your admin installs the enrichment tool, maps the fields, runs the first enrichment batch, and confirms the data shows up. It does, because the admin has System Administrator permissions. Nobody checks whether the SDR profile can see the same fields, because the fields already existed or were created by the package install, not by the admin manually stepping through the field creation wizard.
The other common scenario: the enrichment tool writes to a standard field that's been on the page layout forever, like Mobile Phone. The SDR profile had Read access to Phone but not to Mobile Phone. These are two separate fields with separate field-level security settings, and admins often configure one but forget the other. Phone shows up. Mobile Phone doesn't. The rep sees one phone number but not the direct dial the enrichment tool just found.
How to debug it in 5 minutes
When a rep reports they can't see enriched data, here's the exact sequence to diagnose the problem.
Step 1: Confirm the data exists. Open the record as an admin or use the API to check that the field actually has a value. If the field is blank for the admin too, the problem is the enrichment tool, not permissions. Stop here and check your tool's sync logs.
Step 2: Identify the rep's profile. Go to Setup, then Users, and find the affected user. Note their Profile name. Also note any Permission Sets assigned to them, because permission sets can grant additional field access on top of the profile.
Step 3: Check field-level security for the specific field. Go to Setup, then Object Manager, then Contact (or whichever object), then Fields & Relationships. Click on the field the rep can't see. Click "Set Field-Level Security" (if you've enabled Field-Level Security for Permission Sets in User Management Settings) or click "View Field Accessibility."
You'll see a grid showing every profile and whether it has Visible and Read-Only checked or unchecked. Find the rep's profile. If Visible is unchecked, that's your answer. The rep's profile doesn't grant access to this field.
Step 4: Check the page layout. If field-level security looks correct but the field still doesn't show up, the field might not be on the page layout assigned to that profile. Go to Object Manager, then Contact, then Page Layouts. Open the layout assigned to the rep's profile and verify the field is actually on the layout. Field-level security controls whether the user can access the field at all. The page layout controls where it appears on the screen. Both need to be set correctly.
Step 5: Check for dynamic record pages. If you're using Lightning App Builder pages with field visibility rules, a field can be conditionally hidden based on criteria even if FLS and the page layout are correct. Open the Lightning record page in App Builder and check if any visibility filters are applied to the field's component.
In our case, it was Step 3. The SDR profile had Visible unchecked for Mobile Phone and for our custom LinkedIn_URL__c field. Five-minute fix once we knew where to look.
How to fix it
If field-level security is the problem, you have two options for granting access.
Option A: Update the profile directly. Go to the field's Field-Level Security page, find the profile, check the Visible box (and Edit if reps should be able to modify the field), and save. This is the fastest fix but Salesforce has been moving away from profile-based permissions. They've signaled that permissions will eventually migrate fully to permission sets, though there's no enforcement date yet.
Option B: Create or update a permission set. This is the approach Salesforce recommends. Create a permission set called something like "SDR Enrichment Field Access." Under Object Settings, find Contact, click Edit, and enable Read (and Edit if needed) for the fields your enrichment tool writes to. Then assign the permission set to your SDR users or add it to a permission set group.
Permission sets are additive. They can only grant access, never restrict it. So if the profile blocks a field and the permission set grants it, the user gets access. This makes permission sets safer for incremental changes because you won't accidentally break something else.
If you want to audit the current state of field permissions across your org without clicking through every profile, you can run a SOQL query in Developer Console or Workbench:
Select SObjectType, Field, PermissionsRead, PermissionsEdit, Parent.Profile.Name
From FieldPermissions
Where SObjectType = 'Contact' AND Parent.IsOwnedByProfile = true
This returns every Contact field and which profiles can read or edit it. Filter or sort by the field name your enrichment tool writes to and you'll immediately see which profiles are missing access.
The checklist to run before rolling out enrichment
After going through this once, we built a pre-rollout checklist. Runs through in about 10 minutes and saves you the Tuesday morning support tickets.
- List every field the enrichment tool writes to. Check the tool's field mapping settings. Include both standard fields (Email, Phone, Mobile Phone, Title, Industry) and any custom fields the tool creates.
- For each field, check field-level security across every profile that your sales team uses. If your SDRs, AEs, and managers are on different profiles, check all of them.
- For custom fields created by the enrichment tool's package, explicitly set field-level security. Don't assume the package installer did it correctly.
- Verify each field is on the page layout assigned to each profile. Field-level security says "can they access it." Page layout says "can they see it on screen." Both matter.
- Log in as a test user on each profile and visually confirm the enriched fields show up on a record. Salesforce has a "Login as User" feature under Setup that lets admins do this without needing the rep's password.
- If you're using Lightning record pages with dynamic visibility rules, check that none of the rules hide enriched fields from the rep's view.
This feels like overkill until you've had a sales team running for two weeks on incomplete data because nobody checked field-level security. We've seen this happen with Apollo, Lusha, ZoomInfo, and smaller tools. The enrichment provider doesn't control Salesforce permissions. That's always on the admin.
Why Salesforce built it this way
The separation between object-level and field-level security exists for a good reason. An organization might want all reps to see Contact records but restrict Social Security Numbers to HR. Or allow everyone to see Opportunity records but hide the Discount Percentage from SDRs. Field-level security is how Salesforce handles compliance requirements like HIPAA and GDPR at the field level without building separate objects.
The problem isn't the design. It's that most admin training focuses on object-level access (can you see the tab?) and record-level access (can you see this specific record?). Field-level security gets covered in Trailhead modules but it's easy to forget about in practice, especially when fields are created by third-party packages rather than manually by the admin.
If you're running any enrichment tool on Salesforce, consider field-level security a required step in your rollout, not an afterthought. The 10 minutes it takes to check is a lot less than the cost of a sales team prospecting with incomplete data.
Try it on your own org
Pull up a Contact record in your Salesforce right now. Check whether you can see Mobile Phone, not just Phone. Check whether you can see any custom fields your enrichment tool created. Then ask an SDR on your team to look at the same record and tell you what fields they see.
If the lists don't match, you've got a field-level security gap. The fix takes 5 minutes.
If you're on Salesforce and want to test enrichment with a tool that maps directly to standard Contact fields, ShareCo SalesSync writes to fields like Email, Phone, Mobile Phone, Title, and Company straight from Linkedin. The free tier gives you 40 saves, 10 email enrichments and 3 phone enrichments a month. Before you enrich, run the checklist above so your team actually sees the data once it lands.