Skip to content
The more you know

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.

Show me another one

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

PermissionWhy it is needed
tabsRead the tab a Salesforce page is in, so its title and favicon can be set, and open logins in new tabs or windows.
cookiesRead 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.
storageStore your logins, ORG configurations, quick links and settings locally, and sync the ones you marked as synced.
scriptingInject the ORGanizer button, Quick Links and the console tools into the Salesforce pages you granted access to.
activeTabAct on the tab you are looking at when you trigger a shortcut or a popup action.
downloadsSave the files the extension produces: backups, exports, query results, debug logs, Health Monitor reports.
alarmsSchedule 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.

Granting an ORG's domains from the popup

For the deeper security picture — threat model, cryptography, backend — see the Security Statement and the Privacy Policy.


Show me another one