Salesforce data governance runs on four native access layers, organization, object, field, and record, enforced through login and session policies, profiles and permission sets, field-level security, and org-wide defaults plus sharing rules, with Salesforce Shield and Data 360 Policy-Based Governance layered on top. Snowflake, Databricks, Microsoft Purview, and AWS DataZone each enforce policy differently once data leaves a single system, and Atlan is one of the tools enterprises use to keep that policy consistent everywhere the data actually goes. Salesforce’s own controls are real, audited, and effective inside the CRM. What happens to that data after it leaves is a separate question, and it’s the one this page answers.
Atlan’s Enterprise Data Graph carries lineage and ownership across every connector a business runs, Salesforce included, and Active Ontology keeps a term like “Account” consistent between the CRM and the warehouse it feeds. A few things worth knowing going in:
- Four access layers apply in a fixed order: Org, Object, Field, Record
- Salesforce Shield handles encryption, event monitoring, and audit trail, not policy design
- Data 360 Policy-Based Governance applies rules the same way to a person, an API call, or an agent
- None of these controls were built to travel with the data once it’s copied somewhere else
| What it is | Salesforce’s native access, quality, and security controls: Org-Wide Defaults, role hierarchy, sharing rules, permission sets, field-level security, Shield, and Data 360 Policy-Based Governance |
| Key stat | Four native access layers (Org, Object, Field, Record); Gartner projects 40% of enterprises will demote or decommission AI agents by 2027 over governance gaps |
| Best for | Access, quality, and security control fully inside the Salesforce org |
| Where it stops | Data replicated through reverse ETL, Data Cloud sync, BI extracts, or read by an AI agent outside Salesforce doesn’t inherit these controls automatically |
| Core components | Org-Wide Defaults, role hierarchy, sharing rules, profiles and permission sets, field-level security, Salesforce Shield, Data 360 Policy-Based Governance |
| Structural fix beyond the boundary | A context layer carrying policy and lineage to every system the data reaches |
What is Salesforce data governance?
Permalink to “What is Salesforce data governance?”Salesforce data governance is the combination of native access controls and organizational process that decides who can see, change, and trust the data in a Salesforce org. It is policy plus discipline, not a single feature, and who owns that decision matters as much as the tooling, a gap that shows up constantly once you look at how AI agent governance programs actually run.
Three pillars keep showing up across every credible source on this topic: access (who can see or change a record), accuracy (whether the data is trustworthy enough to act on), and privacy or security (how sensitive fields are protected). Governance in Salesforce is usually owned by admins rather than executives, which explains why data governance implementations fail even when the tooling is sound: nobody with the authority to enforce a rule wrote it. Who owns AI governance is still an open question at most companies, and Salesforce governance inherits that ambiguity.
Salesforce’s tools are real and mature. The question every vendor page on this topic skips is whether that governance holds once the data stops being only in Salesforce, which for any company running analytics, a warehouse, or an AI agent is most of the time.
Data governance vs. data management in Salesforce
Permalink to “Data governance vs. data management in Salesforce”Governance is the rule; management is the work of applying it. A validation rule that blocks a malformed email address is data management. The decision that email addresses must be validated at all, and who signs off on exceptions, is governance. Most Salesforce orgs have plenty of the former and very little of the latter.
How does Salesforce enforce data governance natively?
Permalink to “How does Salesforce enforce data governance natively?”Salesforce enforces access through four layers that apply in a fixed order, and understanding that order is the difference between debugging a permissions issue in minutes versus hours.
| Layer | What it controls | Enforced by |
|---|---|---|
| Organization | Whether a user can log in and access the org at all | Login hours, IP range restrictions, session security policies |
| Object | Whether a user can create, read, edit, or delete a given object type | Profiles and permission sets |
| Field | Whether a specific field on a visible object is readable or editable | Field-level security |
| Record | Which individual records within an object a user can see | Org-Wide Defaults as the baseline, then role hierarchy, sharing rules, and manual sharing as exceptions to it |
Org-Wide Defaults set the record-level floor, Private, Public Read Only, or Public Read/Write. Role hierarchy and sharing rules open up access from there, criteria-based or owner-based, as exceptions to that floor. Profiles set the baseline for what a role can do with an object; permission sets add to it without touching the profile, which is why Salesforce’s own guidance now steers admins toward permission sets as the primary lever, since a profile is a single blunt object where a permission set can be layered and audited independently.
Field-level security is where most of the operational pain concentrates. It has to be set at both the object and field level, and missing one produces a confusing result: a field that’s technically visible per FLS but hidden by a page layout or record type. Enterprises with hundreds of permission sets accumulated over years routinely can’t answer “who can see this field” without querying the underlying permissions object directly. That’s a real governance risk sitting quietly inside a well-designed model.
Precision inside one system is not the same claim as consistency once that data reaches a warehouse, a BI tool, or an agent. That least-privilege logic is exactly what zero trust data governance applies past Salesforce’s own edge, not just inside it.
What do Salesforce Shield and Data 360 Policy-Based Governance each cover?
Permalink to “What do Salesforce Shield and Data 360 Policy-Based Governance each cover?”Shield and Data 360 Policy-Based Governance solve different problems, and they get treated as interchangeable more often than they should be.
| Salesforce Shield | Data 360 Policy-Based Governance | |
|---|---|---|
| What it is | A compliance and audit suite | An attribute-based access control (ABAC) layer |
| Core capability | Platform encryption, event monitoring, field audit trail (up to 10 years), sensitive-data detection | Rules based on user attributes, data attributes (like PII tags), and environment |
| Applies to | Data at rest and user activity inside the org | Access requests, whether from a person, an API call, or an AI agent |
| What it answers | What happened, and is the data encrypted | Should this specific request be allowed right now |
| What it doesn’t do | Design or enforce a governance policy on its own | Replace field-level security or sharing rules |
Shield is compliance tooling: encryption at rest, detailed event logs, and a field audit trail that satisfies regulatory retention windows for frameworks like HIPAA or GDPR. It proves what happened after the fact; it was never built to decide what should happen before the fact, which is Data 360 Policy-Based Governance’s job, enforcing attribute-based rules the same way whether the requester is a person, an integration, or an agent. Shield’s Data Detect component scans for sensitive fields the same way teams handling PII in AI pipelines have to scan for it again once that data moves downstream.
Gartner Senior Director Analyst Shiva Varma named the underlying failure pattern directly: “Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure,” according to Gartner (2026). That’s what happens when a team buys Shield expecting it to also do Data 360’s job, or trusts Data 360’s rules while assuming Shield’s audit trail proves compliance on its own. Neither tool answers the question this page keeps returning to: does the policy still apply once the record leaves Salesforce.
Get the CIO's Guide to Context Graphs
See how governance and lineage extend past any single platform's boundary, in language built for a CDO or CTO audience.
Get the CIO GuideWhat governance gaps appear once Salesforce data leaves Salesforce?
Permalink to “What governance gaps appear once Salesforce data leaves Salesforce?”The same governance that works cleanly inside Salesforce has no native mechanism for traveling with the data once it’s replicated, synced, or queried by something outside the CRM.
Reverse ETL and warehouse sync are the most common exit points. Field-level security and sharing rules don’t automatically re-apply once a record lands in Snowflake or a BI dashboard; a data engineer has to rebuild equivalent row-level and column-level controls by hand, and that rebuild routinely diverges from what Salesforce enforces natively. Salesforce isn’t ignoring this: the 2026 Salesforce-Databricks partnership and Zero-Copy federation are real, current investments aimed at closing the gap. But Zero-Copy federation moves data access across the boundary; it doesn’t automatically move policy enforcement with it, so a record can reach Databricks without the field-level rule that protected it in Salesforce coming along for the ride. That’s the actual gap, not a lack of investment.
Non-human identity is the sharper version of the same problem. According to the Cloud Security Alliance (2026), non-human identities now outnumber human identities by an average of 45 to 1 across the enterprise, climbing to 144 to 1 in cloud-native environments. An AI agent reading Salesforce-origin data, whether Salesforce-native or a general-purpose one built to connect enterprise data sources to LLMs securely, inherits whatever identity model is available to it, and that model rarely has its own governed lifecycle. According to Gartner (2026), 40% of enterprises will demote or decommission AI agents by 2027 over governance gaps found only after production incidents, and separately Gartner (2025) projects over 40% of agentic AI projects will be canceled by the end of 2027 over cost and inadequate risk controls.
Regulatory trails compound it. The EU AI Act requires automatic event logging under Article 12 and a six-month minimum retention period under Article 26(6). Salesforce’s own audit trail covers what happens inside Salesforce well; it wasn’t designed to prove what happened across Salesforce, a warehouse, and whatever agent runtime touched the data in between, which is the compliance surface most enterprises still have to cover on their own.
A governance model scoped to one system does exactly what it was built to do. The gap shows up the moment a company has more than one system, and every company running Salesforce also runs a warehouse, a BI tool, or an agent that reads both.
How do you build a Salesforce data governance framework that holds up for AI agents?
Permalink to “How do you build a Salesforce data governance framework that holds up for AI agents?”Building a governance framework that survives contact with AI agents starts with mapping what already leaves Salesforce, not with buying another tool.
Before you start:
- Inventory every reverse ETL job, Data Cloud sync, and BI extract pulling from Salesforce today
- Identify which agents act with a human’s borrowed permissions versus their own AI agent identity
- Check current audit-log retention against the EU AI Act’s six-month minimum
Five steps:
- Map the native layers as they exist today. Confirm what Org-Wide Defaults, role hierarchy, sharing rules, and field-level security actually enforce right now, not what the documentation says they should.
- Identify every system Salesforce data reaches. Warehouses, BI tools, reverse ETL targets, and any agent with API or MCP access all count.
- Assign clear stewardship. Governance living only with admins has no executive sponsor when a conflict needs a decision, a pattern practitioners describe repeatedly as the reason implementations stall.
- Extend policy context to every downstream system through a shared layer, so a rule enforced in Salesforce doesn’t reset the moment the record crosses into another platform. Preparing enterprise data for AI agents runs on the same principle.
- Build one audit trail spanning every system an agent touches, not just the one Salesforce logs natively.
The most common mistake here is treating Shield as a substitute for the whole program. Shield proves what happened; it doesn’t design the policy, assign the steward, or extend the rule past Salesforce’s edge, and a framework that stops at step one is missing the steps that matter most once you’re scaling agents from a pilot into production.
Take the AI Agent Context Readiness Checklist
See how your Salesforce governance program stacks up against the identity, audit, and cross-system gaps enterprises hit once an agent is reading the data.
Take the ChecklistHow do you choose the right governance layer beyond Salesforce’s native model?
Permalink to “How do you choose the right governance layer beyond Salesforce’s native model?”Choosing what closes the gap comes down to reach, identity handling, audit granularity, and semantic consistency, not whether a tool duplicates a control Salesforce already has.
| Criterion | Why it matters | What to look for |
|---|---|---|
| Cross-system reach | Salesforce data lives in warehouses, BI tools, and semantic layers Data Cloud hasn’t necessarily ingested | A layer spanning every connector, not only Salesforce-native ones |
| Non-human identity handling | 45 to 144 times more non-human than human identities in large enterprises | An explicit agent-identity lifecycle, not borrowed human permissions |
| Audit-trail granularity | EU AI Act traceability needs decision-level detail, not just access logs | Logs capturing which policy version and definition an agent used |
| Semantic consistency | The same field means different things across systems | An active ontology resolving definitions before an agent acts |
| Enforcement point | Policy has to apply without breaking downstream tools | Row and column-level policy context enforced at query time |
Data 360 Policy-Based Governance and Zero-Copy federation address part of this: consistent rule enforcement and access across a growing set of federated systems. Neither one was built to give an agent its own governed identity lifecycle, or to keep a term like “active account” consistent once it’s defined independently in a warehouse, which is why reach alone doesn’t settle the evaluation.
Five questions worth asking any vendor here: does it cover systems Salesforce hasn’t natively synced; how does it handle non-human identity distinct from human role assignment; can it produce an audit trail spanning multiple platforms; does it enforce policy without duplicating work Salesforce already does; and does it resolve business-term definitions consistently everywhere the term appears. Teams asking these questions are usually also weighing how to secure multi-agent systems, broader AI agent risks and guardrails, the parallel self-service analytics governance build vs. buy question, and Agentforce vs. building agents in-house, which turns on an identical reach-versus-control tradeoff. Salesforce governance is one input to that evaluation, not a separate purchase.
How Atlan approaches Salesforce data governance beyond the CRM boundary
Permalink to “How Atlan approaches Salesforce data governance beyond the CRM boundary”Salesforce’s investment in native governance is real; its reach is scoped to the CRM. Enterprises whose Salesforce data feeds a warehouse, a BI tool, or an agent outside Salesforce hit a seam where permissions, definitions, and audit trails stop traveling with the record.
Atlan’s Enterprise Data Graph gives cross-system lineage and ownership spanning every connector a business runs, not just Salesforce. Active Ontology resolves what a term like “Account” or “active customer” means before an agent acts on it, closing the definition drift that shows up when the same object exists in Salesforce and in a warehouse with a slightly different meaning. A native MCP Server for Salesforce gives any agent, whether Agentforce itself, the broader Agentforce 360 platform, or something built outside Salesforce, governed access to that context instead of a borrowed permission set. It’s one instance of a broader shift toward building MCP servers for enterprise data generally. Agentforce’s own coverage and gaps are documented specifically in Agentforce data governance; this page is the platform-wide picture that page’s agent-specific boundary sits inside. Context Agents like Vera and Orion score data quality and map term relationships automatically, addressing the stewardship gap that shows up when governance rules are written ad hoc by whoever happens to be the admin that week.
An agent reasoning over ungoverned or inconsistently governed data is guessing, not answering, which is why AI agent accuracy depends on this boundary as much as model quality. Atlan is a Leader in the 2026 Gartner Magic Quadrant for D&A Governance Platforms and the Forrester Wave for Data Governance, Q3 2025. General Motors, Workday, Mastercard, Nasdaq, and Virgin Media O2 use Atlan for governed context at scale, evidence of a track record extending consistent policy and definitions across a full data estate, not a Salesforce-specific case study.
Real stories from real customers: governance at enterprise scale
Permalink to “Real stories from real customers: governance at enterprise scale”"AI initiatives require more context than ever. Atlan's metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets. As we're doing this, we're making life easier for data scientists and speeding up innovation."
— Andrew Reiskind, Chief Data Officer, Mastercard
"Context is the differentiator. Atlan gave our teams the shared vocabulary and lineage to move from reactive data management to proactive AI enablement."
— Kiran Panja, Managing Director, Cloud and Data Engineering, CME Group
See Atlan in action
Watch how a context layer enforces policy, lineage, and consistent definitions across every system Salesforce data reaches.
Watch the DemoSalesforce governance is real. It just doesn’t travel.
Permalink to “Salesforce governance is real. It just doesn’t travel.”Org-Wide Defaults, role hierarchy, sharing rules, field-level security, Shield, and Data 360 Policy-Based Governance are not marketing claims. They’re audited, well-documented, and getting more capable every release, including through Zero-Copy federation and the Databricks partnership.
None of that changes where the boundary sits. Governance enforced this precisely inside Salesforce has no native way to prove it’s still enforced the moment a record is copied, synced, or read by an agent somewhere else, and for a company of any size that happens constantly. Enterprises evaluating SAP master data governance alternatives hit an identical platform-native boundary, outside Salesforce entirely. Every enterprise running Salesforce alongside a warehouse or a BI tool has already answered the multi-cloud context layer question, usually without realizing it, by whatever ad hoc controls a data engineer built the first time someone asked for a Salesforce export.
Teams that get ahead of Gartner’s 40% figure treat the boundary as a mapped, known fact instead of an assumption. Context engineering is what makes that boundary explicit before an incident forces the question, not after.
FAQs about Salesforce data governance
Permalink to “FAQs about Salesforce data governance”1. What is data governance in Salesforce?
Permalink to “1. What is data governance in Salesforce?”Salesforce data governance is the combination of native access controls (Org-Wide Defaults, role hierarchy, sharing rules, field-level security), Salesforce Shield, and Data 360 Policy-Based Governance, plus the process that decides who owns and enforces those rules.
2. What are the four levels of data security in Salesforce?
Permalink to “2. What are the four levels of data security in Salesforce?”Org, Object, Field, and Record. The organization layer controls login access through settings like IP ranges and login hours, profiles and permission sets control object-level access, field-level security controls individual fields, and record-level access starts with Org-Wide Defaults as a baseline before role hierarchy and sharing rules open it up further.
3. What is the difference between data governance and data management in Salesforce?
Permalink to “3. What is the difference between data governance and data management in Salesforce?”Governance is the policy: what rule applies and who decided it. Management is the execution: the validation rules and automation that enforce the policy day to day. Most Salesforce orgs have more management than governance.
4. What is Salesforce Data 360 governance?
Permalink to “4. What is Salesforce Data 360 governance?”Data 360 Policy-Based Governance is an attribute-based access control layer enforcing rules based on user attributes, data attributes like PII tags, and environmental context, applying the same way whether the request comes from a person, an API call, or an AI agent.
5. How does Salesforce Shield help with data governance?
Permalink to “5. How does Salesforce Shield help with data governance?”Shield handles platform encryption, event monitoring, and a field audit trail retained for up to ten years. It’s compliance and audit tooling that proves what happened; it doesn’t design or enforce governance policy on its own.
6. What is field-level security in Salesforce?
Permalink to “6. What is field-level security in Salesforce?”Field-level security controls whether a user can view or edit a specific field on an object, independent of object-level access. It has to be set at both the object and field level to work as intended.
7. Does Salesforce’s native governance cover data once it leaves Salesforce?
Permalink to “7. Does Salesforce’s native governance cover data once it leaves Salesforce?”Not automatically. Field-level and row-level policies don’t re-apply on their own once data is synced to a warehouse, pulled into a BI tool, or read by an agent outside Salesforce. That policy has to be rebuilt or extended through a shared context layer.
8. Why does data governance matter for Salesforce AI agents?
Permalink to “8. Why does data governance matter for Salesforce AI agents?”Gartner projects 40% of enterprises will demote or decommission AI agents by 2027 over governance gaps found only after production incidents. An agent acting on ungoverned or inconsistently governed Salesforce data carries that same risk, whether it’s Agentforce or a general-purpose agent built elsewhere.
Sources
Permalink to “Sources”- Gearset, “Salesforce Data Governance Explained,” 2026. https://gearset.com/blog/salesforce-data-governance-explained/
- Salesforce, “What Is Data Governance?,” 2026. https://www.salesforce.com/products/data/what-is-data-governance/
- Validity, “Salesforce Data Governance Best Practices,” 2026. https://www.validity.com/blog/salesforce-data-governance-best-practices/
- Flosum, “5 Salesforce Data Governance Best Practices That Prevent Operational Chaos,” 2026. https://www.flosum.com/blog/salesforce-data-governance-best-practices/
- Gartner, “Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure,” 2026. https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure
- Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
- Cloud Security Alliance, “CSA Whitepaper: Non-Human Identity and Agentic AI Governance,” 2026. https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/
- European Union, “EU AI Act, Article 12 - Record-Keeping.” https://artificialintelligenceact.eu/article/12/
- European Union, “EU AI Act, Article 26 - Obligations of Deployers of High-Risk AI Systems.” https://artificialintelligenceact.eu/article/26/
