Security overview

Where data goes

What is stored, where, and for how long

Removing a client deletes its monitoring data from your org straight away. Your org's own backup and retention settings apply to everything stored there.

Access to client orgs

For full monitoring, each client org gets:

• An integration user on the Salesforce Integration licence, which is for API access only.
• A permission set granting: API Enabled, View Setup and Configuration, Monitor Login History, View Event Log Files, View Health Check, View Roles and Manage Data Integrations. Manage Data Integrations is what lets it see Bulk API jobs. It has no Modify All Data and no Manage Users.
• A sharing rule so the integration user can read failed Flow interviews, and only those.
• A small connector app that holds your consultancy's public certificate. Your org signs in with its private key (OAuth JWT bearer). No password is stored anywhere.

Collection only reads. Every call to a client org goes through one guard in the code. The guard refuses anything that isn't a read: another HTTP method, a write hidden inside a batch, or a method override in a URL. Tests check each case.

The right org, every time. Each collection first checks the client's org ID. If it has changed, for example after a sandbox refresh, nothing else is collected until a manager accepts the new org.

Setting up a client with the admin's login

The client admin can let the app do the setup above. They install a setup app once, then approve once with their own login. Before the login, the app lists every change it will make, and the admin agrees to them. Then:

• The login is requested with the api scope only and no refresh token. It returns only to your org's own page, protected with PKCE.
• The run first checks that the login is for the expected client org. If it isn't, nothing is changed.
• It changes only the items on the list. Every change is recorded with the client org ID.
• The admin's token is kept only in a temporary encrypted credential that only the person running the setup can use. It never appears in a record, a response or a log.
• The token is revoked as soon as the setup ends, and a test call confirms it no longer works. A sweep ends any setup left unfinished for over 30 minutes.

Removal can use the same login and reverses every step. It deactivates only users on the Salesforce Integration licence, so no person ever loses access. Admins who would rather not grant a login can use a script or a Setup checklist instead.

Flow error emails

Salesforce writes and sends the standard Flow error email itself. Each client environment gets its own private, randomly named address in your org. An email is accepted only if all of these hold:

• it is from Salesforce, and its DKIM signature for salesforce.com passes;
• it carries the org ID of the client environment that address belongs to;
• it is within that address's limit of 200 emails an hour.

Anything else is rejected and recorded with a reason, without its content.

With full monitoring, an emailed failure stays marked as awaiting confirmation until collection finds the same interview through the API. A Flow-errors-only client has no API connection, so its incidents stay labelled Reported by email, not verified through the API.

Inside your org

• Consultants see only the clients assigned to them. This is enforced by Salesforce sharing, not by hiding things on screen. Managers see every client.
• Only managers can add, pause or remove clients.
• Every add, pause, removal and setup change is audited: who did it, when and to which org.
• Alerts go to the consultants assigned to a client, by email and Salesforce notification, as each person chooses.

What we, the vendor, can see

Nothing inside your org. The app makes one call to us, a daily licence check, which sends:

• your consultancy org's ID;
• whether it is a production or test org;
• the app's version;
• how many client environments are active, in two numbers: full and Flow errors only.

The app shows managers exactly what it last sent. If the check can't reach us, monitoring carries on for 44 days after the last successful check, with a notice to managers. The licensing guide has the details.

Check it yourself

You don't have to take our word for any of this. In your org's Setup:

• Named Credentials and Remote Site Settings list every address the app can call: your client orgs, the Salesforce login hosts used during setup, and our licence service.
• External Credentials show which permission sets can use each connection.
• Email Services lists the address for each client environment.
• In each client org, the integration user's permission set and Login History show exactly what it can do and when it connects.

What we don't claim

• No AppExchange security review yet. We sell directly for now, so Salesforce warns you at install that the package hasn't been through its review. We'll help with your own review.
• Redacting error text is best effort. An error message in a format we don't recognise could still quote a record value.
• Collection keeps some personal data. Collection results keep the running user's name and the full Flow error text for 30 days. We're working on reducing this.
• Email routes. Flow error emails travel between Salesforce's mail servers over TLS. Salesforce doesn't document whether they stay on its own network, so we don't claim that.
• The email format isn't documented by Salesforce and could change. Full monitoring doesn't depend on it, because collection confirms each failure through the API.

Reporting a security issue

Email adam@aokssoftware.com with "Security" in the subject. Please don't include client data.