Sandbox Setup Guide

The security model

Before the how, the why. Four properties of Release Assurance shape the whole setup, and understanding them up front makes every later step obvious.

By design, not by policy

Our control plane refuses to start a run against any Salesforce instance_url that resolves to a production pod. It's a code-level gate with tests around it, not a setting an operator could flip. You never have to trust us to avoid production — the system cannot physically run there.

We drive your UI as a real user

Release Assurance exercises business workflows through Salesforce's own interface. That means all we need is a persona user who can do what a real user does — nothing more. No Setup, no metadata APIs, no direct database access, no custom integration endpoints.

No passwords, no long-lived tokens

Authentication is Salesforce's OAuth 2.0 JWT bearer flow. Every request is a freshly signed JWT; Salesforce verifies it against a public certificate you install; you get back an access token that lives for minutes. There is no password, no refresh token, no persistent session.

One kill switch, in your hands

Trust is granted by a single artifact: the certificate you upload. Remove it and every persona loses access instantly. There are no sessions to invalidate, no keys to rotate on our end, no cleanup for you to chase.

Prepare the sandbox environment

A sandbox prepared for automated regression testing should be representative enough to exercise your workflows and sanitized enough that a mistake costs nothing.

1. Use a sandbox or scratch org — never production

   Full-regression runs require the freedom to create, update, and delete records. That work does not belong in a production org.

2. Strip PII and real customer data

   Refresh from a seeded template, not from a production copy. Scrub names, emails, phone numbers, payment data, and any field that carries PII.

3. Turn email deliverability off

   Set Setup › Email › Deliverability › Access to Send Email to No access, unless your tests specifically need to verify outbound email behavior.

   Why: Prevents any accidental email to real addresses that might still exist in the cloned data.

4. Remove or rotate secrets inside the org

   Scrub named credentials, custom settings, custom metadata, and any other in-org secret stores. We will not read them, but a sanitized sandbox makes this a non-issue in audits.

   Why: Defense in depth. Even though our permission set denies metadata access, a sandbox with no secrets cannot leak any.

5. Keep enough test data to exercise the workflows

   Balance matters: too little and tests can't run; too much real data and risk creeps back in. Use synthetic records, fixture accounts, and anonymized copies.

Create persona users

Give us users who look exactly like your real end users — same profile, same permissions, same app visibility. The whole point is to test what your real users experience; any extra permission we receive invalidates the test.

Username convention

Use a deterministic format so the account is obviously a Release Assurance test account, tied to your org and your sandbox:

Replace persona with the role or name, tenantid with the ID we assign during onboarding, and sandboxname with your sandbox name.

Examples

One persona per distinct role

If your workflows differ by department or title — legal, CSS, sales, service — create a separate persona per role. Don't share one persona across roles; it hides whether a failure is a permissions issue or a workflow issue.

Set up JWT authentication

Release Assurance uses Salesforce's OAuth 2.0 JWT Bearer Flow for server-to-server authentication. On newer orgs you'll configure it through an External Client App; on older orgs it may still be a Connected App.

1. Create the External Client App (or Connected App)

   Enable OAuth and, in the OAuth settings, enable the JWT bearer flow. Request only the scopes we need: api, refresh_token, and web if required. Avoid full.

   Why: JWT bearer is server-to-server. No passwords, no browser login, no user interaction. The app is the narrow door that carries every request.

2. Upload our public certificate

   We provide an X.509 public certificate. Install it on the app's Use digital signatures setting. The matching private key is generated on our infrastructure and never leaves it.

   Why: Salesforce verifies every JWT signature against this certificate. Only a signer holding the matching private key can produce valid tokens — there is no shared password to leak.

3. Set Permitted Users to "Admin approved users are pre-authorized"

   Then grant app access exclusively through the Release Assurance permission set (see part 5).

   Why: Nobody can self-authorize. The only identities that can obtain a token are the dedicated persona users holding the permission set.

4. Keep Login IP Ranges tight — don't relax them for us

   If your org enforces IP restrictions, leave them in place. We'll provide our egress IP ranges so you can allowlist them on the persona profile or the app.

   Why: IP policy is a second factor on top of the certificate signature. A valid JWT from an unexpected network is still refused.

5. Leave token lifetime short; no refresh token

   The JWT flow does not return a refresh token, which is exactly what we want. Access tokens expire within minutes; our control plane re-mints a fresh JWT on every run.

   Why: Short-lived tokens bound the blast radius of any single token. A copied token expires before it can be meaningfully used, and cannot be extended.

6. Know how to revoke

   Revocation is one step: remove our certificate from the app, or delete the app itself. Access ends immediately for every persona.

   Why: Trust rests on one artifact you own. No sessions to kill, no passwords to reset, no tokens to blacklist.

Create the Release Assurance permission set

One permission set, assigned to the persona users, does two things: lets them authenticate through the JWT flow, and makes them identifiable as test personas without giving them anything extra.

Disable in-app guidance and feedback popups

Salesforce walkthroughs, prompts, and feedback surveys can cover buttons or change focus mid-click. For a UI-driven test run, a pop-up is a silent failure.

Setup › In-App Guidance › Settings

• Turn off Salesforce Standard In-App Guidance
• Turn off Custom In-App Guidance

Setup › User Interface › Adoption Assistance

Disable all three toggles:

Extra hardening recommendations

None strictly required for Release Assurance to work, but each reduces risk meaningfully. These are what we'd do if we were in your seat.

Go-live checklist

One list, in order. Walk through it top to bottom and you're ready for onboarding. Print it, paste it into a ticket, or share it with your security reviewer for sign-off.