Compare Salesforce Field Level Security (FLS) settings across profiles and permission sets. Copy FLS from one field, paste to another, and diff across orgs.
Coments dal svilupadĂ´rs
FLS Comparator lets Salesforce admins capture, compare, and apply Field-Level Security settings across fields and orgs â entirely in-browser, no external server.
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.
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.