10.4 Security, Access, and Reporting Integrated Lab

Lab scenario: access without overexposure

A growing company has sales reps, service agents, sales managers, support supervisors, and executives in one Salesforce org. Sales reps should manage their own accounts and opportunities. Service agents should work cases and see related account context, but not edit opportunity amounts. Managers should see team records. Executives should see dashboards, but not necessarily administer Salesforce. The admin must build access that supports work and reporting without granting broad system permissions as a shortcut.

Start with the security model from the outside in. Profiles and permission sets answer whether a user can access an object, field, tab, app, or system capability. Organization-wide defaults, role hierarchy, sharing rules, teams, queues, manual sharing, and restriction rules where used answer which records a user can see. Field-level security controls whether a user can see or edit a field even if the page layout contains it. Reports and dashboards add another layer with folder sharing, source report access, running user behavior, and the viewer's underlying record visibility.

Create a baseline profile strategy. In a modern org, keep profiles lean and use permission sets for job-based access. Build or select a Standard User style profile where appropriate, then create permission sets such as Sales Rep Access, Service Agent Access, Sales Manager Access, Support Supervisor Access, and Executive Dashboard Viewer. Assign only required object permissions and app access. Avoid giving View All Data, Modify All Data, Customize Application, or Manage Users unless the role truly needs administration power.

These permissions are high blast radius and should not be used to fix a missing field or report.

Set object and field access deliberately. A sales rep may need read, create, edit on Leads, Accounts, Contacts, Opportunities, Tasks, Events, and Campaigns depending on the process. A service agent may need read on Accounts and Contacts, read and edit on Cases, and possibly read on Assets or Entitlements. Opportunity Amount might be read-only or hidden for service agents. Test by opening records, editing fields, creating records, and using list views.

Failure mode: page layout hides a field, but field-level security still allows API or report exposure, or field-level security hides a field and users blame the page layout.

Configure record access. If org-wide defaults for Opportunities are Private, sales reps see their own opportunities, managers see subordinate records through the role hierarchy when Grant Access Using Hierarchies applies, and sharing rules or teams can open exceptions. If Cases are Private, queues and assignment define ownership but do not automatically give every supervisor access unless roles, sharing, or permission design supports it. Public Read/Write may be tempting in a lab, but it avoids the administrator judgment the platform expects. Choose a restrictive baseline, then open access based on business need.

Build reports that expose the access model. Create a My Open Opportunities report, Team Pipeline report, Open Cases by Queue report, and Executive Forecast Snapshot report. Store them in folders with clear sharing: Sales Reports for sales users and managers, Service Reports for service staff, Executive Dashboards for executives. Then test as each persona. A sales rep should not see all company opportunities if sharing is private. A manager should see team records. A service agent should not see Opportunity Amount if field-level security hides it.

The executive should see dashboards only if folder and dashboard settings allow it.

Pay special attention to dashboard running user choices. A dashboard running as a named executive or admin can display records the viewer could not otherwise see in source reports, depending on dashboard type and permissions. A dynamic dashboard can show data according to the logged-in user's access. The right choice depends on the purpose. A board-level metric might intentionally use a consistent running user. A manager coaching dashboard might be better as dynamic so each manager sees their own team. Document the intended behavior and test it.

Add a troubleshooting routine. When a user cannot see a field in a report, check object permission, field-level security, report type availability, page layout only if the issue is on the record page, and whether the field is included in the custom report type. When a user cannot see a record in a report, check ownership, OWD, role hierarchy, sharing rules, teams, queues, manual shares, territory or account team behavior if used, and report filters. When a user cannot open a report, check folder sharing and report permissions. Do not fix every issue by making the user a system administrator.

Review prompts before the quiz:

• What is the difference between object access and record access in your test org?
• How would you prove a hidden field is protected by field-level security and not only page layout removal?
• Which reports should run as the viewer, and which need a fixed running user?
• What permission would be too broad for a manager who only needs dashboards?
• Where would you document expected access by persona?