3.1 Standard Permission Sets, User Roles & Functional Access

Standard Permission Sets, User Roles & Functional Access

Security in Salesforce Data Cloud operates at the intersection of traditional Salesforce Platform access governance and high-scale lakehouse infrastructure. Unlike standard Sales or Service Cloud applications where record access is managed primarily through profiles, role hierarchies, and sharing rules, Data Cloud relies on a modern, decoupled identity and access model built upon Permission Set Licenses (PSLs), Standard Permission Sets, and Data Spaces.

A fundamental architectural principle tested heavily on the consultant exam is that core Salesforce profiles (including System Administrator) do not grant administrative or functional access to Data Cloud by default. A user with the System Administrator profile who attempts to open Data Cloud will encounter blank tabs, missing setup menus, or access restriction errors until granted the appropriate Data Cloud Permission Set License and functional permission set.

---

The Layered Security Model in Data Cloud

To configure and govern access effectively, consultants must understand how Data Cloud permissions layer onto the Salesforce core platform:

1. Feature Licenses & Provisioning: At the tenant level, Data Cloud entitlements are provisioned into the Salesforce org, enabling underlying lakehouse storage, streaming ingestion services, and Hyperforce microservices.
2. Permission Set Licenses (PSLs): Every user requiring interaction with Data Cloud must first be assigned a Data Cloud Permission Set License (such as Data Cloud User or Data Cloud Admin license). The PSL unlocks the capability envelope for that user's seat.
3. Standard Permission Sets: Salesforce ships a small set of pre-configured standard permission sets that grant discrete, role-specific functional rights across the ingestion, modeling, identity resolution, segmentation, activation, and governance pipelines. This list was redesigned on 4 September 2025, so any study material naming a "Data Cloud Marketing User" or "Data Cloud Privacy Manager" permission set is describing objects that do not exist in the product.
4. Permission Set Groups (PSGs): In enterprise deployments, organizations bundle Data Cloud standard permission sets with core CRM permission sets (e.g., combining CRM Campaign management with Data Cloud Segmentation) to establish streamlined job-based access.
5. Data Space Associations: In multi-brand or multi-region organizations, functional permission sets are scoped to specific Data Spaces to enforce row-level and metadata isolation.

---

The Current Standard Permission Sets (Post-September 2025 Redesign)

Salesforce rebuilt the Data 360 standard permission sets on 4 September 2025, and the official Data 360 License, Credits, and Permission Set Changes article is the authority a consultant should quote. Three things changed simultaneously, and all three surface in scenario questions:

1. Data Cloud Admin was renamed Data Cloud Architect. The underlying permissions did not change; the label did. Access to Salesforce Setup still requires the user to hold a Salesforce Admin role or the Customize Application permission — a Data 360 permission set on its own never unlocks Setup.
2. Four permission sets were marked Legacy: Data Cloud Marketing Admin, Data Cloud Data Aware Specialist, Data Cloud Marketing Manager, and Data Cloud Marketing Specialist. They keep working, but Salesforce no longer updates them, so users holding only a Legacy set do not gain access to newly released objects and features.
3. Two activation permission sets were added: Data Cloud Activation Manager and Data Cloud Activation Specialist. Both grant broader access than the marketing manager and marketing specialist sets they replace.

A Data Cloud Governance Specialist permission set and an AI-oriented permission set were announced alongside this redesign and then placed on hold. Do not design a security model around them, and do not select them as an answer.

1. Data Cloud Architect (formerly Data Cloud Admin)

The Data Cloud Architect permission set is the platform-owner persona: provisioning, connector integration, modeling, identity resolution, and tenant-wide configuration.

• Primary Responsibilities: Configures native connectors (Salesforce CRM, Amazon S3, Google Cloud Storage, Microsoft Azure Blob, Web & Mobile SDKs, Ingestion API) and their external credentials; creates and schedules Data Streams; maps Data Lake Objects (DLOs) to Data Model Objects (DMOs); designs custom DMOs; configures Identity Resolution rulesets; authors Calculated and Streaming Insights; creates activation targets, data action targets, data shares, and data graphs; provisions and assigns Data Spaces.
• Scope of Access: The broadest standard set — Data Explorer, Profile Explorer, Query Editor, Data Cloud Setup pages, and the administrative APIs.
• Consultant Note: Because the rename was label-only, an org provisioned before September 2025 and one provisioned after behave identically; only the permission set name a user sees in Setup differs.

2. Data Cloud User

The Data Cloud User permission set is the consumption persona for frontline service agents, sales executives, and analysts who need visibility into unified data without authoring rights.

• Primary Responsibilities: Views Data 360 features and unified profiles — Profile Explorer searches, Data Cloud-related lists and copy-field enrichments surfaced on Lead, Contact, Account, and Person Account Lightning record pages, and Data 360 reports built for them by others.
• Role Boundaries: Read-only. Cannot create data streams, edit mappings, configure identity resolution, build segments, or publish activations.

3. Data Cloud Activation Manager

The Data Cloud Activation Manager permission set owns the audience and activation surface end to end — the successor to the legacy Marketing Manager role.

• Primary Responsibilities: Creates, edits, and manages segments; creates activation targets (including Marketing Cloud Engagement, cloud file storage, advertising platforms, and Salesforce core targets); builds and publishes activations; creates real-time data action targets; runs queries.
• Role Boundaries: Does not configure source connectors or data stream credentials, and does not author the canonical data model. It is an audience-operations role layered on top of a model someone else built.

4. Data Cloud Activation Specialist

The Data Cloud Activation Specialist permission set is the day-to-day execution persona — the successor to the legacy Marketing Specialist role.

• Primary Responsibilities: Builds and runs segments, executes and monitors activations, and queries Data 360 data.
• Role Boundaries: Has view rather than manage access to shared configuration such as activation targets. Salesforce documents two known limitations worth remembering: Activation Specialists can see Data Share Targets even though they cannot view or edit Data Shares, and neither the Activation Manager nor the Activation Specialist can open the Query Editor.

5. The Legacy Permission Sets

(Legacy) Data Cloud Marketing Admin, (Legacy) Data Cloud Data Aware Specialist, (Legacy) Data Cloud Marketing Manager, and (Legacy) Data Cloud Marketing Specialist remain assignable in existing orgs. The consultant guidance is consistent: migrate users off them using User Access Policies, because feature-gated objects released after September 2025 are not added to Legacy sets. A "the feature works for the admin but is invisible to the marketing team" symptom in a long-lived org is very often an unmigrated Legacy permission set.

6. The Auto-Assigned Integration Permission Sets

When Data 360 is enabled in an org, the Platform Integration User is automatically assigned Data 360 Salesforce Connector (API name sfdc_c360a_sfdctrust_permSet) or Customer 360 Data Platform Integration (API name sfdc_a360_trust_permSet), and the Salesforce Standard Data Model package is installed. These are machine identities, never assigned to humans. If someone has stripped them from the Platform Integration User, CRM ingestion and cross-product calls break in ways that look like connector failures.

---

Where Privacy and Deletion Rights Actually Live

There is no standard "privacy manager" permission set in Data 360. Privacy operations are split across two different mechanisms, and the exam tests the split:

• Data subject deletion / right to be forgotten in Data 360 is submitted through the Consent API using the shouldforget action. This is an API operation performed by a user or integration with Data 360 API access — typically a Data Cloud Architect or a service integration — not a dedicated privacy persona.
• Right to Be Forgotten (RTBF) policies in Privacy Center are a separate Salesforce product that erases or masks records on a policy schedule and requires the Privacy Center license. If a scenario says "policy-driven, scheduled, applies across the core org," that is Privacy Center, not the Consent API.

---

Functional Permissions Matrix

The following matrix outlines how core operational tasks distribute across the current standard permission sets. Memorizing these functional boundaries is essential for scenario-based exam questions.

Exam Trap — the vanished marketing roles. Older prep material (and several popular question banks) still names a "Data Cloud Marketing User" or "Data Cloud Privacy Manager" permission set. Neither has ever existed. The marketing-shaped roles were Data Cloud Marketing Admin / Manager / Specialist, all of which are now Legacy, and their supported replacements are Data Cloud Activation Manager and Data Cloud Activation Specialist.

---

Ingestion Security: FLS, OLS & Integration Users

When ingesting data from external sources, particularly connected Salesforce CRM orgs (Sales, Service, and Custom Cloud instances), Data Cloud enforces strict object-level and field-level security boundaries at the ingestion point.

The Salesforce CRM Connector Integration User

When a Salesforce CRM connector is authorized, Data Cloud communicates with the source org using the Salesforce CRM Integration User. This integration user operates with a dedicated profile and permission sets in the source CRM environment.

• Field-Level Security (FLS) Impact: If a custom field on a CRM object (e.g., Annual_Recurring_Revenue__c on Account) has FLS set to hidden or lacks Read permission for the Integration User in the source org, that field will not appear in the Data Stream field selection wizard in Data Cloud. The field cannot be ingested or mapped until FLS is updated in the source CRM org.
• Object-Level Security (OLS) Impact: If the Integration User lacks Read access to a custom or standard object in the source CRM org, that object cannot be selected as a source entity when creating a new data stream.
• Decoupling After Ingestion: Once data is successfully ingested into a Data Lake Object (DLO) and mapped to a Data Model Object (DMO), source CRM record-level sharing rules and FLS no longer govern the Data Cloud environment. Within Data Cloud, access is governed strictly by Data Cloud permission sets and Data Spaces.

---

Data Explorer vs. Profile Explorer: The Critical Exam Distinction

A frequent source of exam confusion is the distinction between Data Explorer and Profile Explorer. While both provide data visualization, they serve fundamentally different personas and data layers:

---

Real-World Exam Troubleshooting Scenarios

Scenario 1: The Missing Ingestion Field

• Problem: A data specialist is creating a data stream for the Contact object from a connected Salesforce CRM org. They need to ingest the custom field Loyalty_Tier__c, but the field is entirely absent from the data stream configuration list.
• Root Cause: The Salesforce CRM Connector Integration User in the source Salesforce org lacks Field-Level Security Read permissions for Loyalty_Tier__c.
• Resolution: An administrator in the source CRM org must grant Read access on Loyalty_Tier__c to the integration user's profile or assigned permission set, then refresh the data stream schema in Data Cloud.

Scenario 2: The Marketer Requesting Raw Data Inspection

• Problem: A digital marketing manager wants to inspect incoming raw mobile app telemetry events to verify whether an event timestamp is populating correctly before building a segment. They report that they cannot locate the Data Explorer tab.
• Root Cause: The user holds an activation-oriented permission set (Data Cloud Activation Manager or Data Cloud Activation Specialist), which intentionally omits Data Explorer and the Query Editor so that audience operators cannot issue unbounded queries against raw lakehouse tables.
• Resolution: The marketer uses Profile Explorer to inspect unified profile records, or asks a Data Cloud Architect to inspect the raw DLO events in Data Explorer. Granting the Architect set purely to view one stream is the wrong answer — it is a tenant-wide administrative role.

Scenario 3: Activation Publishing Inactive

• Problem: A marketing user successfully authors an audience segment, but the "Publish" button on the activation remains disabled, and the target Marketing Cloud business unit cannot be selected.
• Root Cause: The activation target has not been assigned to the user's active Data Space, or the user lacks the specific activation permissions required for that destination.
• Resolution: A Data Cloud Admin must associate the desired Activation Target with the marketing user's Data Space, enabling the user to link their segment to the target.

Scenario 4: Core Administrator Access Denied

• Problem: A company's Salesforce System Administrator attempts to access the Data Cloud Setup tab to configure an Amazon S3 connector but receives an "Insufficient Privileges" error.
• Root Cause: Standard Salesforce profiles do not confer Data 360 rights. The System Administrator has not been assigned the Data Cloud Permission Set License and the Data Cloud Architect standard permission set.
• Resolution: Assign the user the Data Cloud PSL and the Data Cloud Architect standard permission set in Setup > Users. Note the reverse dependency too: the Architect permission set does not by itself grant Salesforce Setup access, which still requires a Salesforce Admin role or the Customize Application permission.