sf-access-explainer

SF Access Explainer

A Chrome extension (Manifest V3) that, on any Salesforce Lightning record page, shows whether a chosen user has Read/Edit/Delete access to that record and explains why: enumerating every sharing source that grants it.

No OAuth, no external services, no dependencies. It reuses your existing browser session against Salesforce (the sid cookie) to call the REST API directly.

Load the extension (unpacked)

1. Open chrome://extensions in Chrome.
2. Enable Developer mode (top-right toggle).
3. Click Load unpacked.
4. Select this folder (the one containing manifest.json).
5. Pin the extension if you’d like quick access from the toolbar.

Using it

1. Log in to your Salesforce org as usual and navigate to any Lightning record page, e.g.: https://yourorg.lightning.force.com/lightning/r/Account/001XXXXXXXXXXXXXXX/view
2. Click the extension icon.
3. The popup shows:
   • Access Verdict: Read/Edit/Delete badges plus max access level, transfer, and full-access flags, computed from UserRecordAccess.
   • Why: every sharing source that grants access: object-level ViewAllRecords/ModifyAllRecords overrides, record ownership, manual shares, sharing rules, teams, implicit sharing, territories, and Apex managed sharing, each attributed to the specific share row and access level.
   • What was checked: every query run, including shares that exist on the record but don’t apply to the target user, so a “no access” verdict is fully explainable.
4. Click Switch user to search for and inspect a different user (Id, Name FROM User WHERE Name LIKE ...). The default target is always yourself.

How it works

• background.js (service worker) is the only place that reads the httpOnly sid cookie, via chrome.cookies.get. It maps the Lightning host to the API instance host (<mydomain>.lightning.force.com → <mydomain>.my.salesforce.com) and calls https://<instanceHost>/services/data/v63.0/... with Authorization: Bearer <sid>.
• popup.js parses the active tab’s URL for /lightning/r/<Object>/<Id>/, determines standard vs. custom object handling, and drives the queries by messaging the service worker (chrome.runtime.sendMessage).
• common.js holds shared constants/helpers (API version, host mapping, share-table naming, RowCause decoding) used by both the popup and the service worker.

Known edge cases handled explicitly

• Standard vs. custom share tables differ in table name, foreign key, and access-level field all at once (e.g. AccountShare.AccountId / AccountAccessLevel vs. Invoice__Share.ParentId / AccessLevel). Both are built correctly per object.
• No share table: if OWD is Public Read/Write or the object is Controlled by Parent, the *Share query throws an invalid-sObject error. This is caught and surfaced as a banner, not a crash; access is then explained purely via object-level permissions.
• Inspecting another user requires View All Data. If the UserRecordAccess query fails for a non-self target, the popup shows a clear banner instead of failing outright. Self-inspection always works.
• API Access Control / expired session (401) is surfaced as a banner, not a silent failure.
• Role hierarchy is not recursively expanded (v1 scope). Share rows granted to Role/RoleAndSubordinates/Territory groups are always listed and labeled “via role hierarchy (not fully expanded)”, with direct GroupMember membership checked and called out when confirmed.

Permissions

• cookies: read the sid session cookie for the Salesforce instance host.
• activeTab: read the current tab’s URL to detect the record context.
• storage: reserved for future use (no persistent data is currently stored).
• host_permissions for *.salesforce.com and *.force.com: call the Salesforce REST API on the instance host.

Out of scope (v1)

• OAuth / Connected App flow.
• Full recursive role-hierarchy expansion.
• Sandbox/Visualforce/legacy-domain host mapping beyond the single .lightning.force.com → .my.salesforce.com replacement.
• Editing anything: this is a read-only diagnostic tool.