Connecting
How to connect your Salesforce org
Five steps, about two minutes. Read-only throughout — nothing is written to your org at any point.
Before you start
You need a Salesforce login for the org you want scanned, and in most orgs that login needs to be a System Administrator — see the first question below for why, and what to do if it is not.
Nothing is installed in your org. There is no package, no metadata deployment, and nothing to uninstall afterwards.
Step by step
Choose how to sign in
Production is the usual answer. The other two are here because many orgs need them — pick a sandbox to try it somewhere safe first, or use your own Salesforce URL if your org has disabled the generic login host.
›My org uses its own login URL
Copy it from your browser's address bar while you are logged into Salesforce — acme.my.salesforce.com, a sandbox URL, or a Lightning URL all work.
Sign in at Salesforce
You are sent to Salesforce, not to a form here — we never see your password. If your org uses SSO or MFA, that happens as normal.
Approve two permissions
Salesforce shows what is being asked for: api to read your configuration, and refresh_token so a long scan can finish. Nothing else is requested, and you only ever see data your own Salesforce profile already permits.
Refused instead of asked? That is org policy, not a mistake you made — the error page names which setting, and this page is what to send your admin.
You land back here, connected
You arrive at a page showing your org name, ID and the scopes granted. That page only renders after we have used the token to make a real API call, so it is evidence the connection works rather than evidence the redirect fired.
Run the scan
A few minutes, depending on how much Apex and how many Flows the org has. You get a complexity score, an inventory and the top issues for free. Scans are capped at 3per hour per org and only one runs at a time, to protect your org’s daily API allocation.
Common questions
›Do I need to be a Salesforce administrator?
In most orgs, yes. Since September 2025 Salesforce blocks connected apps that are not installed in your org, and the permission that allows them — Approve Uninstalled Connected Apps — is on the System Administrator profile by default. A non-admin can still connect if an admin grants that permission. If your org has API Access Control enabled, an admin has to approve the app regardless of who is connecting.
›Can I try this on a sandbox first?
Yes, and it is a reasonable way to see the report before pointing it at production. Use the sandbox option on the connect screen. Bear in mind a sandbox is only as useful as it is current — a refreshed-yesterday full copy tells you a lot, a years-old developer sandbox tells you very little about your real pricing configuration.
›My org does not allow login.salesforce.com. What now?
Paste your own Salesforce URL instead — the one ending in .my.salesforce.com. The connect screen accepts it directly and sends you to your own domain to sign in. Many orgs disable the generic login host entirely, so this is common rather than exotic.
›What exactly is it asking permission for?
Two OAuth scopes: api, to read configuration, and refresh_token, so a scan that runs longer than a short-lived access token can finish. Salesforce has no read-only variant of the api scope, so read-only is enforced on our side — the Salesforce client issues GET requests and has no write path at all. You only ever see data your own Salesforce profile already permits.
›Will this slow down or affect my production org?
It issues read-only API calls, the same kind any integration makes, and writes nothing. The visible cost is API call consumption against your org's daily allocation, which is why scans are capped at 3 per hour per org and only one scan runs at a time.
›How long does the connection last, and how do I revoke it?
Until you revoke it. You can disconnect from inside the app, or independently in Salesforce under Setup → Connected Apps OAuth Usage, which takes effect immediately and does not require telling us. Disconnecting from the app also revokes the token at Salesforce rather than only deleting our copy.
›I connected fine, but the scan failed. What happened?
The scan reads a lot more than sign-in does, so it can hit limits sign-in never touches. The failure message names which: API access disabled for the org, the connected user lacking Read on the CPQ objects, the org's daily Salesforce API allocation being spent, or an IP restriction that only bites once we call the API from our server rather than from your browser. Each has a different fix, and the report page states which one you hit rather than guessing.
›It worked before and now asks me to reconnect. Why?
Salesforce rotates the credential we hold and expires it after a period of disuse, and an admin can revoke it at any time from Setup. When that happens the connection is marked disconnected rather than left looking healthy, and reconnecting takes a few seconds — no data is lost, and your previous reports stay exactly where they were.
›Why did my connection fail?
The error page names the cause rather than saying 'connection failed'. The three common ones are an IP restriction on your Salesforce profile, an app awaiting admin approval, and an org that requires its own login URL. The first two are org policy and cannot be fixed by retrying — send your Salesforce admin the access requirements page.
If your org’s security settings block the connection, that is not something retrying will fix. Send your Salesforce admin the access requirements — it lists exactly what to allow, and why.
Related
What we read — the specific objects and fields, and what is never touched.
What breaks in a migration — the incompatibilities the scan looks for.