3.4 Record Access Troubleshooting and Login-As Workflow

Troubleshoot The Symptom Before The Setting

A record access complaint usually arrives as a vague statement: I cannot see the account, I cannot edit the case, the report is missing rows, or my manager can see too much. The admin's first job is to turn that complaint into a precise test. Identify the user, object, record, requested action, interface, and expected business reason for access. Then compare actual behavior to the designed model.

Do not start by making OWD more open or assigning System Administrator. Those changes can solve the ticket while creating a security incident. Instead, gather evidence and work through the access stack. In a production org, follow the organization's support, privacy, and change-control rules. In a Trailhead Playground, practice the same sequence with test users so the workflow becomes automatic.

The Record Access Stack

Use a predictable order. First, confirm the user can log in and is active. Second, check the user's license, profile, permission sets, and permission set groups for object permission. Third, check whether any broad permission explains the result. View All on an object bypasses record sharing for read access to that object. Modify All on an object bypasses sharing for edit and delete style administration on that object. View All Data and Modify All Data are broader org-level permissions and should be rare.

Fourth, inspect the record's owner, OWD, role hierarchy path, sharing rules, public groups, teams, queues, territories, manual shares, and implicit access. Fifth, check newer visibility constraints such as restriction rules where the org uses them. A restriction rule can narrow which records certain users see even when sharing grants broader access. Finally, inspect non-sharing blockers: validation rules, flows, approval locks, duplicate rules, required fields, and page-specific behavior.

Login-As Workflow

Login-As lets an authorized admin open Salesforce as another user to reproduce a reported experience. Setup path commonly starts from Setup > Users > Users, then the Login link where available and permitted. Org settings and policy determine whether admins can log in as users and whether user consent is required. Treat this capability with care because you may see or affect real user data.

A professional Login-As workflow looks like this:

1. Record the support case, user, expected action, and business owner approval if required.
2. Review user permissions first so you know what you expect to see.
3. Log in as the user only long enough to reproduce the issue.
4. Avoid changing business data unless the support process explicitly authorizes it.
5. Capture configuration evidence rather than personal data where possible.
6. Log out of the user session and return to your admin session.
7. Apply the least-privilege fix in configuration or data ownership.
8. Retest as the user or with a clean test user.
9. Document the cause, fix, and any access risk discovered.

Login-As is useful because admins often see more than ordinary users. If an admin tests a page as themselves, a hidden field, private record, or missing tab may look fine. Logging in as the affected user can confirm the symptom. It does not explain the root cause by itself. You still need to inspect the permission sources.

Access Decision Lab

Scenario: Priya is a support agent. She can open Case C-100 but cannot edit Status. Case OWD is Private. Priya is on the case team with Read/Write access, her profile grants Case Read and Edit, and Status is visible and editable by FLS. When she saves, a validation error says Closed cases cannot be changed after manager approval. The access model is probably not the blocker. The save failure is business logic or approval state.

Scenario: Daniel can see every opportunity in the org even though Opportunity OWD is Private and he is not above every owner in the role hierarchy. He has a permission set with View All on Opportunity. That explains read access without changing OWD. If the business does not approve that broad visibility, remove or adjust the permission assignment rather than rebuilding sharing rules.

Scenario: Mei cannot see account A-200. She has Account Read, no View All, Account OWD is Private, she does not own the account, her role is not above the owner, and no sharing rule, team, territory, or manual share includes her. The least-privilege fix depends on business pattern. If she needs one account, add an account team or manual share. If her team needs a category of accounts, use a sharing rule or territory model. If every user should see every account, revisit OWD with stakeholders.

Troubleshooting Checklist

Before closing an access ticket, answer these questions:

• What permission source gave or denied object access?
• What record sharing path gave or denied record access?
• Was any broad permission involved?
• Did field-level security or layout behavior affect the symptom?
• Did validation, automation, approval, duplicate rules, or locking affect save?
• Was the issue reproduced as the affected user or an equivalent test user?
• Was the fix least privilege and documented?

This checklist is exam useful because many answer choices fix a symptom at the wrong layer. If the user lacks object Read, sharing will not help. If the user lacks a record sharing path, adding a field to a layout will not help. If a validation rule blocks save, changing the role hierarchy may not help.

Exam Traps

Access is not only see versus cannot see. Salesforce has read, create, edit, delete, transfer, report, export, approve, and administrative actions. A user may be able to view a record, edit some fields, and fail on one operation. Read the verb in the scenario.

Be careful with inherited access. Managers may see subordinate records through role hierarchy. Account owners may receive implicit access to related opportunities, cases, or contacts depending on object relationships and settings. Users in queues may access queued records. A correct answer often comes from recognizing one of these record access paths rather than changing permissions.