Why Does a New Salesforce Field Break Your Integration? A Field-Level Security Audit Checklist (2026)

You add one new custom field to the Lead object on a Tuesday afternoon. By Wednesday morning, your integration user can’t see it, a nightly sync job silently drops the value on every record it touches, and nobody notices until someone asks why a report has been empty for a week. Salesforce didn’t throw an error. It just quietly did exactly what field-level security told it to do. If you’ve never run a real field-level security audit across your integration users, profiles, and permission sets, this is the gap that eventually causes it. This is the exact audit we run for clients during a Cloud Nexus org review, laid out here as the same checklist so you can run it yourself before the next field goes missing.

1. New Fields Default to Hidden: Why Does Adding a Field Break Existing Access?

A new custom field defaults to hidden for every profile except System Administrator unless you explicitly grant access during creation. Salesforce’s field creation wizard asks about field-level security by profile on its own screen, and it’s easy to click through it under deadline pressure or trust a permission set that was never actually updated. Consequently, the field works perfectly for whoever created it, while every other profile — including the integration user — sees nothing.

Fix: Treat the field-level security screen in the field creation wizard as a required step, not an optional one. Explicitly grant access for every active integration user’s profile or permission set before saving, not just the profiles obviously affected. Add this as a line item on whatever change log already governs your validation rules, since it’s the same kind of change that needs the same kind of review.

2. Integration Users Miss a Dedicated Permission Set: Why Does the Connector Still Lack Access After You Fixed the Profile?

The connector still lacks access because most integration users run on a stripped-down profile, and editing that shared profile directly affects every other user assigned to it. As a result, admins often avoid touching it, and the field-level security gap never actually gets closed. Permission sets exist specifically to grant additional access without touching the base profile, but only if someone builds one for the integration user in the first place.

Fix: Create one dedicated permission set per integration user — one for the Pardot connector, one for any middleware service account, one for each scheduled API job — and grant field-level security there instead of on the shared profile. Assign the permission set directly to the integration user. Keep a documented list of exactly which permission set maps to which integration, the same list this checklist keeps referencing.

3. Blocked Fields Fail Silently on Some API Paths: Why Doesn’t Anyone Notice Until Data Is Missing?

Some Salesforce API contexts silently drop a value on a field the running user can’t see instead of throwing an error, while others throw a clear insufficient-access fault. Bulk API operations and certain SOAP or REST update paths behave differently depending on API version and whether the request touches one field or many. In practice, a clean sync log does not guarantee every field actually synced.

Fix: Never assume a clean sync log means every field synced. Spot-check a sample of recently created or updated records against the source system after any new field goes live. Confirm the field-level security screen was actually completed for every integration user, not just the ones you remembered.

4. Nobody Documents Which Fields Each Integration Actually Needs: Why Does Every New Hire Repeat the Same Discovery?

Without a documented map of which fields each integration user actually touches, every new field, new integration, or new hire rediscovers the dependency the hard way, usually through a broken sync. The knowledge lives in one admin’s memory instead of anywhere written down, and it leaves the org the moment that admin does.

Fix: Maintain a simple field-to-integration matrix — one row per integration user, one column per object, and a note on which fields that integration reads or writes. Update it the same day a new field gets mapped to an integration, not after the next incident forces the question.

5. Field-Level Security Never Gets Re-Audited After Go-Live: Why Does Access Drift Over Time?

Field-level security drifts because orgs keep adding fields, reorganizing permission sets, and onboarding new profiles long after the original implementation, and nobody revisits the original access map to keep it current. Each individual change looks small on its own. Over a year or two, the gap between what the documentation says and what’s actually configured widens until nobody trusts the documentation at all.

Fix: Put a quarterly field-level security audit on the same calendar as your validation rule and duplicate rule reviews. Pull the list of fields added since the last audit, check each one against every active integration user’s profile and permission sets, and update the field-to-integration matrix as you go.

The Field-Level Security Audit Checklist

This is the same six-step pass we run during a Cloud Nexus org review, built to be repeatable rather than a one-time cleanup.

Why Should Field-Level Security Be Part of Your Change Governance Process?

Field-level security belongs in the same governance process as validation rules and duplicate rules, because all three fail for the same underlying reason: a change ships without anyone checking who else depends on that object. A new field is not just a schema change. It’s a permissions change that every integration user needs to be included in, every time.

This is exactly the kind of dependency we map out during a Cloud Nexus org review, checking field-level security, validation rules, and duplicate and matching rules together against every integration touching the org, instead of auditing each one in isolation. Our broader Salesforce security best practices checklist covers where field-level security fits into the wider picture.

Frequently Asked Questions

How is field-level security different from a validation rule blocking a sync?

A validation rule actively rejects a save that violates a condition, which usually produces a visible error in the sync log. Field-level security is quieter — it can simply prevent a value from being read or written without necessarily throwing an error, depending on the API path. Our guide on Salesforce validation rule governance covers the louder failure mode; this post covers the quiet one.

How often should we audit field-level security?

Run the checklist any time a field is added or modified on an object with an active integration, and again on a standing quarterly cadence regardless of whether anything obviously changed. Most mid-market orgs find quarterly catches drift before it causes a real incident, without becoming its own maintenance burden.

Does field-level security work the same way with Permission Set Groups?

Mostly, but with one added wrinkle: Permission Set Groups support muting, which can intentionally revoke access a member permission set would otherwise grant. If your org uses Permission Set Groups, check for active muting on any field-level security setting before assuming a group grants the access its individual permission sets suggest.

Can I test field-level security changes in a sandbox first?

Yes, and you should. Field-level security changes test cleanly in a full or partial sandbox, including running a sample sync through the integration user to confirm the field actually populates, not just that the permission appears correctly in Setup.

How do I get help auditing our field-level security?

A Cloud Nexus org review is a free 90-minute session where a senior consultant walks your integration users, profiles, and permission sets against every object your integrations touch. You leave with a prioritized list of exactly which fields are exposed to which risk, not a generic security score.