Learn one feature at a time
A random page of the ORGanizer documentation, so you pick up something new without reading all of it at once.
Domain permissions
Rebuilt in 1.0
ORGanizer used to ask, at install time, for access to every Salesforce domain in existence. It no longer does. It now ships with no Salesforce access at all and asks for one ORG's domains at a time, when you first open that ORG — and you can revoke any of them later.
Permissions granted at install time
| Permission | Why it is needed |
|---|---|
tabs | Read the tab a Salesforce page is in, so its title and favicon can be set, and open logins in new tabs or windows. |
cookies | Read the Salesforce session cookie of the ORGs you are logged into. This is how the popup knows which ORGs are active, and how the tools call the API as you. |
storage | Store your logins, ORG configurations, quick links and settings locally, and sync the ones you marked as synced. |
scripting | Inject the ORGanizer button, Quick Links and the console tools into the Salesforce pages you granted access to. |
activeTab | Act on the tab you are looking at when you trigger a shortcut or a popup action. |
downloads | Save the files the extension produces: backups, exports, query results, debug logs, Health Monitor reports. |
alarms | Schedule the periodic housekeeping the background worker does (licence refresh, log retention). |
Plus a small set of hosts, which are ORGanizer's own backend — never Salesforce:
https://api.organizer.solutions/*— licence validation and promo codes;https://organizer.solutions/*— this site, for the in-popup messages and the change log.
Dropped in 1.0
identity and identity.email (the Google sign-in used by the removed
Google Drive backup), clipboardRead, unlimitedStorage, the
googleapis.com host and the browsing-history access are all gone. The extension
no longer knows your Google identity or your email address.
Salesforce domains: optional, and per ORG
Salesforce domains are declared as optional host permissions. The declaration is
a broad wildcard, but that is only the ceiling of what ORGanizer may ever ask for — it is
never requested as such. What is actually requested is the specific set of origins belonging to
the ORG you just opened. For acme.my.salesforce.com, that is:
https://acme.my.salesforce.com/*
https://acme.lightning.force.com/*
https://acme.vf.force.com/*
https://acme.file.force.com/*
https://acme.my.salesforce-setup.com/*
Sandboxes, developer and scratch ORGs get the same set with their own partition segment
(.sandbox., .develop., .scratch.). All five are requested in
a single browser prompt, because each request needs its own click.
login.salesforce.com, test.salesforce.com and
welcome.salesforce.com — the last one serves the
email-based login flow — are not My Domains, so they are
separate origins. The popup offers to pre-authorise them the first time you use it —
without them a stored login cannot be opened until its ORG's own domain has been granted, which
makes for a confusing first run. You can decline, and tick don't ask again.
api.status.salesforce.com is optional too, and requested only when you open the
Health Monitor, which reads instance status from it.
Reviewing and revoking
Options → Permissions lists everything you granted, grouped by My Domain. Each group can be revoked on its own, and you can also grant a domain manually before visiting it. Revoking takes effect immediately: the content scripts are unregistered from those origins.
On Firefox
Firefox draws its permission prompt behind the extension popup, so a request fired from the popup would block on a dialog you cannot see. On Firefox, ORGanizer therefore hands the grant over to the Options page and closes the popup — the prompt then appears where you can answer it.
For the deeper security picture — threat model, cryptography, backend — see the Security Statement and the Privacy Policy.
Show me another one