6.6 Analytics Security, Visibility, and Executive Reporting

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

6.6 Analytics Security, Visibility, and Executive Reporting

Key Takeaways Explain This Topic AI

Analytics visibility is governed by object permissions, field-level security, record sharing, report and dashboard folders, and dashboard running user behavior.

Executive reporting must balance broad decision visibility with least privilege and clear definitions for each KPI.

Users need the right report permissions to create, customize, run, export, subscribe, or manage public reports and dashboards.

Agentforce and AI-assisted analytics require the same data access discipline, grounding review, testing, and monitoring as other trusted admin features.

Last updated: May 2026

The layers of analytics security

Salesforce reporting security starts before the report builder opens. A user needs access to the object, the fields, the records, and the folder that contains the report or dashboard. They also need functional permissions such as Run Reports, Create and Customize Reports, Report Builder, Export Reports, Subscribe to Reports, Manage Public Reports, or Manage Dashboards in Public Folders depending on the task. A user who lacks object access will not fix the issue by receiving a report link. A user who lacks field-level access should not see that field just because it is on a report.

Record visibility comes from organization-wide defaults, role hierarchy, sharing rules, teams, territories, manual sharing, queues, account relationships, and broad permissions such as View All or View All Data. Reports respect the accessible rows for the running user of the report. Dashboards add another layer because a specified running user can summarize data using that user's access. That is useful for executive reporting, but it must be governed so sensitive aggregate information is not exposed casually.

Layer Controls Scenario symptom

Object access Profile, permission set, permission set group User cannot report on the object at all.

Field access Field-level security Field is missing or hidden in report results.

Record access Sharing model and owner-based access User sees fewer rows than a manager.

Report folder Folder sharing User cannot find or open the report.

Dashboard folder Folder sharing User cannot view the dashboard.

Dashboard running user Specified user or dynamic dashboard Dashboard totals differ from the user's report results.

Export and subscribe Report permissions and org policy User can view but not export or schedule delivery.

Executive reporting also requires definition control. A KPI such as net new pipeline can mean created date this quarter, close date this quarter, stage not closed, forecast category included, or amount converted to corporate currency. If each region uses a different report, leadership will argue about definitions instead of decisions. Admins should capture KPI definitions, source reports, filters, currency handling, fiscal calendar assumptions, and owner of each metric.

A report that is technically correct can still be unsafe. Exported CSV files may contain personal data, regulated information, or competitive sales details. Once data leaves Salesforce, Salesforce sharing no longer protects it. Admins should grant export permissions deliberately, classify sensitive fields, consider data loss prevention processes outside Salesforce, and train users not to email uncontrolled spreadsheets when a secured report subscription or dashboard would be better.

Visibility troubleshooting and AI-era reporting

When a stakeholder says a report is wrong, avoid guessing. Use a structured visibility path. First, run the report as yourself and capture the total. Then inspect the report type, filters, filter logic, date field, and scope. Next, log in as or use approved troubleshooting tools for a representative user if policy allows, or compare with a user who has similar permissions. Check object permissions, field-level security, record sharing, role hierarchy, territories, and folder access. For dashboards, check the running user and refresh time.

Troubleshooting workflow:

Confirm the business definition of the number being disputed.

Check source report type, filters, date fields, grouping, and row count.

Verify the viewer's object, field, record, and folder access.

Check dashboard running user, dynamic setting, filters, and last refresh time.

Compare a known record that should appear with one that should not appear.

Document whether the issue is data quality, security, report design, or timing.

Agentforce and AI-assisted experiences do not remove these rules. Admin-level Agentforce work focuses on use cases, permissions, prompt and agent configuration boundaries, testing, trust, deployment, monitoring, and feedback. If an agent summarizes pipeline or answers executive questions, it must be grounded in approved data and tested with realistic user personas. The admin should verify that the agent does not reveal records, fields, files, or report details beyond the user's authority. AI output should be treated as a generated response that needs governance, not as a new security boundary.

Use Agentforce where it helps users act on trusted information, such as summarizing a visible account plan, explaining why a dashboard metric changed, or guiding a service manager to cases that already appear in their queue. Do not use AI to bypass report access, infer hidden data, or make regulated decisions without human review and approved controls. Monitor usage, feedback, audit signals, and data grounding quality after deployment. If the data is stale, duplicated, or poorly secured, AI will amplify the issue.

Executive dashboards should have owners and review cycles. A quarterly operating dashboard should be reviewed after changes to fiscal year settings, territory models, sales stages, case milestones, products, currencies, or automation. If a KPI depends on imported data from an external system, include the load status or freshness indicator. Leaders need to know whether they are looking at current data, a snapshot, or a stale refresh.

Study trap: do not grant View All Data or Export Reports to solve every analytics complaint. Broad permissions can create serious exposure. If the problem is a missing folder share, grant folder access. If the problem is a private sharing model, evaluate sharing rules or role hierarchy. If the problem is a dashboard that should show each viewer only their own rows, use a dynamic dashboard when available. The right fix is the smallest permission and design change that meets the reporting requirement.