Salesforce FLS Comparator Expanded
Compare Salesforce Field Level Security settings across fields and orgs
Skann QR-koden for å åpne denne utvidelsen i Firefox for Android
Metadata for utvidelser
Skjermbilder
Compare Salesforce Field Level Security settings across fields and orgs
PERMISSIONS
storage — persists FLS snapshots and apply-history in browser.storage.local only. Nothing is sent remotely.
tabs — identifies which tab holds an active Salesforce session to retrieve the correct instance URL.
cookies — Salesforce marks its session token ("sid") HttpOnly, so document.cookie in a content script cannot read it. The background service worker reads it via browser.cookies.get() on the Salesforce host, uses it as a Bearer token for REST/Tooling API calls back to that same org, and never stores or transmits it elsewhere.
host_permissions (.salesforce.com, .lightning.force.com, .my.salesforce.com, .sandbox.my.salesforce.com, .develop.my.salesforce.com, .salesforce-setup.com variants) — required for the background worker to make authenticated fetch() calls to the Salesforce REST and Tooling APIs. The wildcard is necessary because orgs use unpredictable customer-specific subdomains.
CONTENT SCRIPT
salesforce-bridge.content.ts runs on Salesforce domains only. It detects Set Field-Level Security pages via URL pattern and injects a launch button. It reads nothing beyond what is already in the page URL. The background worker rejects any message from a content script whose sender tab is not a recognised Salesforce hostname.
HOW TO TEST
Requires a free Salesforce Developer Edition org (developer.salesforce.com/signup).
1. Open any page in the org after logging in.
2. Open the FLS Comparator sidebar (View → Sidebar → FLS Comparator).
3. Select an object (e.g. Contact) and field (e.g. Email), then click Fetch FLS.
4. The table shows Read/Edit access for every Profile and Permission Set in the org.
No eval(), no remote scripts, no telemetry. All network traffic goes only to the user's own Salesforce org.