Salesforce Data Governance: Policies That Keep Agents and Reports Honest

Salesforce lets you record, on every field, who owns the data, how sensitive it is, which regulations apply and whether the field is still in use. All four values are queryable through the API and reportable through a custom report type.

Then Salesforce tells you, in one sentence on its own documentation page, what that classification does at runtime: *changing the value of Field Usage doesn’t hide or expose the field.*

Read that carefully, because it defines the entire discipline. Salesforce ships the vocabulary for a data policy and declines to enforce it. Classification is a label, not a control. Everything below follows from that gap, and the gap widened the moment agents started reading the same data your reports read.

Salesforce data governance is the set of policies determining what data means, who owns each definition, how sensitive it is, how long it is kept and who may see it. Platform change control is a separate discipline covered in the governance framework. This page is about the records rather than the configuration.

Salesforce classifies every field in four dimensions

The vocabulary is more complete than most orgs realize, and data classification carries no add-on cost. Editing the values requires the Customize Application or Modify Data Classification permission.

Salesforce’s definitions of the sensitivity values are unusually precise and worth adopting verbatim rather than inventing your own. Confidential covers data available to an approved group, not restricted by law but shareable under an NDA. Restricted is available only to an approved group and likely restricted by law, regulation, an NDA or a master service agreement. MissionCritical narrows that to a small group where third parties could face heightened contractual requirements.

Data Owner carries the most governance weight of the four. Salesforce describes the owner as the person who understands the importance of the field’s data and might be responsible for determining its minimum sensitivity level. That is a named accountability, recorded on the field, which is exactly what most data policies lack.

Two limitations to plan around. These metadata fields are unavailable for the User object in Object Manager, so applying them there requires the CustomField Metadata API or the Data Classification Upload tool. And compliance categorizations do not appear on fields suffixed __pc when querying Person Account, so the Contact object has to be queried instead.

Classification becomes enforceable policy through FieldDefinition

A policy nobody can query is a document. The reason classification is worth the effort is that every value maps to an API field.

Which makes governance questions answerable as queries rather than as meetings. Which fields on Account and Contact carry no owner. Which fields marked Restricted appear in a report type available to every user. Which fields were flagged DeprecateCandidate a year ago and still hold data.

Salesforce also documents the reporting path, and it is not obvious enough to guess. Create a custom report type with Entity Definition as the primary object, then add Field Definitions as the child object. That produces a report over your own classification metadata, which is the artifact a governance forum should review rather than a spreadsheet somebody maintained once.

Bulk operations exist for orgs that cannot classify field by field. The Data Classification Upload tool accepts a CSV of up to 10,000 rows, each naming an object, a field and a sensitivity level. The download tool returns only fields that already carry a sensitivity value, which makes the gap between the two counts a useful coverage metric.

Agents read through profiles, and masking is switched off for them

Here the label-versus-control distinction stops being academic.

An agent’s data access is governed by identity, not by sensitivity, and Salesforce publishes the mapping by agent type. Employee agents run as the logged-in end user, governed by that user’s profile, permissions, field-level security and sharing rules. Sales development agents run as an EinsteinSDRAgent User. Service agents without credential-based user verification run as an EinsteinServiceAgent User, and with verification enabled on Enhanced Chat v1 and Experience Cloud sites, as the logged-in site user.

Salesforce adds a line worth reading twice: context variables tell the agent who the user is but do not control data access. Knowing who is asking and deciding what they may see are separate mechanisms, and only the second one governs anything.

So a field marked MissionCritical is read by an agent exactly as readily as a field marked Public, provided the running user can see it. Sensitivity classification never enters the decision.

Then the detail that surprises most teams. On the page covering what the Einstein Trust Layer masks, Salesforce states plainly: data masking for LLMs is disabled for agents. Masking remains available for embedded generative features such as Einstein Service Replies and Work Summaries, and is configurable in Trust Layer setup. For agents, it is off.

Agent actions running flows can escalate past the running user

The natural conclusion from the section above is that field-level security and sharing are the last line of defence. Salesforce documents a path around both, and it is the single most important governance detail on this page.

When an agent action runs a flow, Salesforce states that both the flow’s run context and the agent’s execution context apply. Flows run in one of three contexts, and the published table is unambiguous about what each grants:

Two of the three grant access to all objects and all fields. One of those two ignores sharing entirely.

So an agent whose running user has carefully scoped field-level security can still invoke an action that reaches a flow running in system context, at which point the scoping stops applying to the data that flow touches. Salesforce also notes that when a service agent runs in agent user context, the running user of the flow is the agent user rather than the customer, which means the flow inherits the agent user’s reach and not the person’s.

That makes the reviewable unit an agent’s action list rather than its user record. Approving an agent means approving every flow its actions can invoke, and checking the run context of each. The security review is the operative document, and agent ownership after go-live becomes a data decision rather than a support arrangement.

Data 360 converts tags into enforcement, and core Salesforce does not

The asymmetry is worth stating directly, because it determines where a serious policy can actually run.

In Data 360, governance is policy-driven. Salesforce’s wording is explicit: object-level and field-level security policies in Data 360 are driven by tags and classifications, enabling scalable governance across large numbers of objects and fields. The operational consequence follows in the next line, that when new data is ingested you give it the correct tag and existing rules apply automatically without extra work.

That is the thing core Salesforce classification does not do. Same conceptual vocabulary, same four-way sensitivity framing, entirely different runtime behavior.

Three tiers, then, and a policy has to specify which one it operates in:

A governance charter that says sensitive data is protected, without naming the layer, is describing a Data 360 behavior while most of the org runs on the first row.

Reports disagree for reasons unrelated to data quality

Before blaming records, rule out the mechanics, because two users running one report can legitimately see different numbers with perfectly clean data.

Salesforce’s own knowledge base attributes divergent record counts to differences in field-level security, private sharing settings, role hierarchy restrictions and time zone differences affecting date filters. A separate article addresses the harder case where users share the same role and profile and still differ, including administrators with View All Data, and identifies locale mismatch as the most common cause: locale determines the time zone applied to date filters, so filter boundaries shift per user.

Roll-up summary fields contribute their own quiet failures. Salesforce documents that if a roll-up filter references a formula field returning an error, no matches are returned for that criterion, so the summary silently excludes records. Salesforce also notes that campaign roll-up values are not recalculated when a lead or contact is deleted, and that a mass recalculation must be triggered manually.

None of those is a data quality problem. All of them produce the same symptom: a meeting where two people hold different numbers from the same system. A data policy that only addresses record accuracy will not fix any of them, which is why the definition layer below matters as much as the cleanliness layer.

Four policies carry most of the weight

Data governance sprawls when written as an aspiration. Four policies, each with a named owner and a queryable state, cover the majority of what goes wrong.

Definition. Every metric and every field that feeds one has a written definition and a single owner. What counts as an active customer. Which of the four revenue fields is authoritative. This is the policy that stops two reports disagreeing for reasons neither analyst can explain, and it is the one most orgs skip because it is a business conversation rather than a technical task.

Classification. Every field carries a Data Owner and a Data Sensitivity Level, set through Setup or the upload tool, and the coverage gap is reported quarterly through the Entity Definition report type described above.

Retention. How long each category of record is kept and what happens at the end. This becomes urgent once agents ground answers in historical records, because an agent citing a four-year-old closed case is technically correct and commercially wrong.

Access. Which profiles and permission sets can read each sensitivity level, reviewed whenever an agent is granted a permission set. Given that agents inherit user visibility and bypass LLM masking, this is the only policy standing between a Restricted field and a model.

Duplicate rules, matching logic and survivorship belong to adjacent disciplines rather than to this list. Those are covered in duplicate management and master data management, and both assume the definition policy above already exists.

Governance programs correlate with measured trust

The evidence base here is thinner than the topic deserves, so the figures worth citing are the ones carrying stated samples.

Salesforce’s State of Data and Analytics, second edition, surveyed 3,800 data and analytics leaders and 3,852 business leaders between 27 June and 13 August 2025. Those leaders estimate 26 percent of their organizations’ data is untrustworthy. Among those with AI in production, 89 percent report having experienced inaccurate or misleading outputs. And only 43 percent have established formal data governance frameworks and policies, while 88 percent believe AI advances demand new governance approaches.

The payoff figure comes from the 2026 State of Data Integrity and AI Readiness, produced jointly by Drexel University’s LeBow College of Business and Precisely, surveying 505 data and analytics leaders at organizations with at least 1,000 employees or $250 million in revenue. Organizations with governance programs report high trust in their data at 71 percent, against 50 percent without.

A third source deserves a caveat alongside its numbers. Validity, which sells CRM data quality tooling into the Salesforce ecosystem, surveyed 500 marketing professionals across five countries in August 2026 and reports that 92 percent of SVP and VP respondents have acted on an AI recommendation they later suspected was wrong because of bad underlying data. Treat it as vendor-commissioned, and note that it measures exactly the failure this page exists to prevent.

Scoring your own position before buying more agents is the subject of data readiness assessment, and cleaning what the assessment surfaces belongs to org cleanup.

Scope agents against classified data rather than against enthusiasm

The practical sequence runs classification first, agent scope second, because an agent’s blast radius is the set of fields its running user can read.

GetGenerative.ai packages this as fixed-scope delivery rather than open-ended discovery, with a catalog of pre-scoped agents mapped to Salesforce objects, three fixed-price packages and Trust Layer configuration included in every engagement. Teams can see the pre-scoped agent catalog and match candidate agents against the fields those agents would actually read.

The pairing matters more than either half. A pre-scoped agent against unclassified data inherits whatever the running user can see. A classified org with no agent scope discipline has documentation and no control. Doing both in sequence is what makes the answer defensible when someone senior asks where a number came from. Preparing the underlying records is covered in agent-ready data quality.

Recap. Salesforce classifies fields across compliance, ownership, sensitivity and usage, exposes all four through FieldDefinition, and enforces none of them in core. Agents read through the running user’s profile and sharing, with LLM masking switched off, and an agent action reaching a flow in system context can bypass that scoping entirely. Data 360 does drive security policies from tags. Reports diverge through locale, sharing and roll-up mechanics rather than through dirty records. Four policies cover most of it: definition, classification, retention, access.

Key facts

FAQ

What is Salesforce data governance?

Salesforce data governance is the set of policies defining what data means, who owns each definition, how sensitive it is, how long it is retained and who may access it. It differs from platform governance, which controls who may change configuration. Both are needed, and each requires separate owners.

Does Salesforce field classification restrict access?

No. Classification records Compliance Categorization, Data Owner, Data Sensitivity Level and Field Usage, and Salesforce states that changing Field Usage does not hide or expose the field. Access remains controlled by field-level security, profiles, permission sets and sharing rules regardless of the sensitivity value recorded.

Can Salesforce data classification be reported on?

Yes. All four attributes map to FieldDefinition API fields: ComplianceGroup, BusinessOwnerId, SecurityClassification and BusinessStatus. Salesforce documents a custom report type using Entity Definition as the primary object and Field Definitions as the child object to expose them in standard reports.

Do AI agents respect data sensitivity classifications?

No. Agent access is governed by the running user’s profile, permissions, field-level security and sharing rules rather than by sensitivity labels. Salesforce also documents that data masking for large language models is disabled for agents, though it remains available for embedded generative features.

Can an agent see more data than its running user?

Yes, through flows. Salesforce documents three flow run contexts, and two of them grant access to all objects and fields, with system context without sharing ignoring sharing rules. An agent action invoking such a flow operates beyond the running user’s field-level scoping.

Why do two users see different numbers in the same Salesforce report?

Salesforce attributes this to field-level security differences, private sharing settings, role hierarchy restrictions and time zone differences affecting date filters. Where role and profile match, locale mismatch is the common cause, because locale sets the time zone applied to date filter boundaries.

Which data governance policies matter most?

Four carry most of the weight: definition, giving every metric a written meaning and a single owner; classification, recording owner and sensitivity on every field; retention, deciding how long each record category persists; and access, controlling which profiles read each sensitivity level.