9.2 Trusted AI, Security, Data Access, and Permission Implications

Salesforce Admin Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Administrator Orientation and Official Source Control

1.1 Credential Name, Current Outline, and Search Language 1.2 Exam Format, Fee, Score, and Reference Rules 1.3 Trailhead, Trailhead Academy, and Pearson VUE Delivery Workflow 1.4 Domain Weights, Agentforce, and Study Prioritization 1.5 Maintenance Modules, Credential Ethics, and Exam Security 1.6 Developer Edition, Trailhead Playground, and Practice Bank Workflow

2 Chapter 2: Configuration, Setup, User Management, and Org Controls

2.1 Company Information, Fiscal Year, Business Hours, and Locale 2.2 User Records, Licenses, Profiles, Permission Sets, and Login Access 2.3 Login Security, Session Settings, and Identity Basics 2.4 Setup Navigation, Release Readiness, and Change Control 2.5 UI Settings, Home Pages, Apps, and Navigation 2.6 Configuration and Setup Case Lab

3 Chapter 3: Security, Access, Identity, and Sharing Model

3.1 Org-Wide Defaults, Roles, Sharing Rules, and Teams 3.2 Profiles, Permission Sets, Permission Set Groups, and Muting 3.3 Field-Level Security, Page Layouts, and Dynamic Forms 3.4 Record Access Troubleshooting and Login-As Workflow 3.5 Identity, Login History, MFA, and Session Risk 3.6 Data Visibility, Reporting, and Analytics Security 3.7 Security and Access Case Lab

4 Chapter 4: Object Manager, Lightning App Builder, and Data Modeling

4.1 Standard Objects, Custom Objects, and Schema Fit 4.2 Fields, Formulas, Rollups, Validation, and Requiredness 4.3 Lookup, Master-Detail, and Junction Relationships 4.4 Record Types, Business Processes, Page Layouts, and Lightning Pages 4.5 Dynamic Forms, Dynamic Actions, and User Experience 4.6 Schema Change Risk, Data Quality, and Deployment Readiness 4.7 Object Modeling Case Lab

5 Chapter 5: Sales, Marketing, Service, and Support Applications

5.1 Lead, Campaign, Account, Contact, and Opportunity Flow 5.2 Sales Processes, Path, Products, Price Books, and Forecasting 5.3 Case Management, Queues, Assignment, Auto-Response, and Escalation 5.4 Knowledge, Entitlements, Service Console, and Support Productivity 5.5 Sales-Service Data Quality and Automation Boundaries 5.6 Application Configuration Troubleshooting 5.7 Sales and Service Applications Case Lab

6 Chapter 6: Data and Analytics Management

6.1 Data Import Wizard, Data Loader, Export, and Backup 6.2 Duplicate Management, Validation, and Data Quality Controls 6.3 Data Transfer, Ownership, Mass Update, and Mass Delete 6.4 Report Types, Filters, Summary Formulas, and Buckets 6.5 Dashboards, Components, Subscriptions, and Sharing Impact 6.6 Analytics Security, Visibility, and Executive Reporting 6.7 Data and Analytics Case Lab

7 Chapter 7: Automation, Flow, Approval, and Operational Processes

7.1 Automation Tool Selection and Order of Execution 7.2 Flow Builder: Screen, Record-Triggered, Scheduled, and Autolaunched Flows 7.3 Approval Processes, Email Alerts, and Notification Patterns 7.4 Validation Rules, Assignment Rules, and Escalation Rules 7.5 Automation Testing, Debugging, and Governance 7.6 Automation Performance, Recursion, and Maintainability 7.7 Automation Case Lab

8 Chapter 8: Productivity, Collaboration, Mobile, and AppExchange

8.1 Activities, Tasks, Events, Calendar, and Email Productivity 8.2 Chatter, Feeds, Groups, Notifications, and Collaboration Governance 8.3 Salesforce Mobile Navigation, Actions, and Page Design 8.4 List Views, Kanban, Path, and User Adoption Tools 8.5 AppExchange Evaluation, Installation, Permissions, and Risk 8.6 Productivity and Collaboration Case Lab

9 Chapter 9: Agentforce for Platform Administrators

9.1 Agentforce Use Cases, Admin Boundaries, and Fit 9.2 Trusted AI, Security, Data Access, and Permission Implications 9.3 Agent Builder, Prompt Builder, and Grounding Concepts 9.4 Testing, Deployment, Monitoring, and Feedback Workflows 9.5 Agentforce Service, Sales, and Internal Productivity Scenarios 9.6 Agentforce Risk, Troubleshooting, and Governance 9.7 Agentforce Case Lab

10 Chapter 10: Integrated Salesforce Admin Scenario Labs

10.1 New Sales Org Setup Integrated Lab 10.2 Service Team Case Management Integrated Lab 10.3 Data Quality and Analytics Integrated Lab 10.4 Security, Access, and Reporting Integrated Lab 10.5 Flow Automation and Change Control Integrated Lab 10.6 Agentforce and Adoption Integrated Lab 10.7 Full Admin Simulation Strategy

11 Chapter 11: Final Review, Maintenance, and Test-Day Strategy

11.1 Final 30-Day Salesforce Admin Review Plan 11.2 Trailhead Playground Hands-On Drill Plan 11.3 105-Minute Exam Timing, Flagging, and Review Workflow 11.4 Test-Day Checklist: Online or Test Center 11.5 Post-Exam Maintenance Modules and Next Certifications 11.6 Salesforce Admin Final Mixed Review

9.2 Trusted AI, Security, Data Access, and Permission Implications

Key Takeaways Explain This Topic AI

Agentforce trust starts with normal Salesforce controls: licenses, profiles, permission sets, permission set groups, object permissions, field-level security, sharing, and app access.

An agent should be grounded only in data and content that the organization is prepared to expose for that audience and channel.

Builder access and user access are different; admins can delegate agent-building permissions without granting broad Setup access when supported.

Security testing must include restricted users, hidden fields, private records, external users, and unsupported requests.

Last updated: May 2026

Trust starts with Salesforce security

Trusted AI is not a slogan for admins; it is an implementation discipline. Agentforce uses Salesforce configuration, data, actions, and channels, so the same security questions still apply. Who is the user? What license do they have? Which app and tab can they access? What objects, fields, records, files, and knowledge articles can they see? Which actions can they run? Which audit trail proves what changed?

A common exam trap is assuming the agent is a special superuser. Do not. Admins should design agents so users receive help within approved access boundaries. If a service rep cannot see a field because field-level security hides it, an agent response should not reveal that field by summarizing it from another source. If an Experience Cloud user cannot see another customer account, a customer-facing agent should not expose that account through a grounded answer.

Control layer Admin question Agentforce implication

License and feature access Is Agentforce available for this org and user type? Availability can depend on edition, add-on, agent type, and channel.

Builder permission Who can create, edit, test, and activate agents? Use permissions such as Manage AI Agents and agent-type permissions where applicable.

Runtime access Who can use the agent? Assign the app, tab, channel, or permission set for the intended audience only.

Object and field access What data can be read or changed? Grounding and actions must respect CRUD, FLS, and action permissions.

Record access Which records are visible? Private sharing, role hierarchy, sharing rules, teams, territories, and external sharing matter.

Audit and feedback What evidence is kept? Monitor conversations, feedback, errors, and changes under approved retention policies.

Builder access and runtime access are different. A business operations lead might need to help design an internal productivity agent, but that does not mean the person should receive System Administrator, Modify All Data, or unrestricted Setup access. Current Agentforce Studio guidance supports access through the App Launcher and feature-specific permissions, such as Manage AI Agents, with additional permissions depending on the agent type. The admin should use permission sets and permission set groups to assign only the required capabilities.

User permissions also govern agent actions. If an agent can trigger a flow, invoke an action, update a case, create a task, or retrieve a knowledge article, those capabilities must be reviewed the same way any automation entry point is reviewed. The admin should ask whether the action runs in user context, system context, or a named integration context, and whether the result could expose data the user should not see. If context is unclear, test it with restricted users before production.

Grounding deserves special care because it determines what the agent can use as source context. Approved grounding might include public knowledge articles, internal knowledge, CRM records, Data Cloud segments, uploaded documents, or an Agentforce data library. Each source has a security classification. A public warranty FAQ is not the same as a case transcript, product defect spreadsheet, or employee HR policy. The admin should tag sources by sensitivity before connecting them.

Security test checklist:

Ask for records the user should not see and verify the agent refuses or cannot retrieve them.

Ask for hidden fields, restricted files, unpublished knowledge, and private records.

Test external users separately from employees because sharing models differ.

Test actions that create or update records and confirm ownership, required fields, validation rules, and sharing side effects.

Review conversation logs, feedback records, and audit data for sensitive data exposure.

Confirm deactivation and rollback steps before opening access to a broader audience.

External channels raise the risk level. A customer-facing agent in Experience Cloud or chat must be tested for authentication state, guest access, account relationship, contact relationship, and data leakage between customers. Guest and unauthenticated access is especially sensitive. If the business wants a public agent, start with public content and no record-specific actions unless the identity and sharing design is fully approved.

Admins should also think about prompt and response data. Users may paste sensitive information into a conversation. If conversation, feedback, or audit data is stored for monitoring, the organization must decide who can view that data, how long it is retained, and whether it can include personally identifiable, financial, health, or regulated details. Monitoring is useful only when the monitoring data is governed.

Study trap: do not solve an agent access problem by making everyone more powerful. If Agentforce Studio is not visible, check app visibility, profile or permission set assignments, tab settings, feature enablement, and required agent permissions. If an agent cannot answer from a knowledge article, check publication status, data category visibility, channel availability, and user access before changing broad permissions. Least privilege is still the admin standard.