Connect a Salesforce sandbox.
Salesforce sandboxes only, with a non-admin user. Never production, Developer Edition, scratch orgs or Playgrounds. Connecting Milita is a short, guided conversation. You stay in control of access the whole way, and nothing is ever installed inside your org.
Sandboxes only
We connect only to Salesforce sandboxes. Connect with your sandbox's My Domain URL, such as acme--release.sandbox.my.salesforce.com. Production orgs, Developer Edition orgs, scratch orgs and Trailhead Playgrounds are refused at connect time by an org-type check, with no exception, so a misconfiguration can't point us at live data. A full or partial sandbox that mirrors your real configuration gives the most faithful coverage.
A dedicated non-admin integration user
You create a dedicated integration user for Milita with the minimum permissions needed to exercise the processes in scope. It must not be an admin: a user with the System Administrator profile, or with Modify All Data, View All Data, Customize Application or Author Apex, is refused when you connect, and so is one whose permissions we cannot read. This keeps the blast radius small and makes access easy to review and revoke.
Certificate-based sign-in
We authenticate using the OAuth 2.0 JWT Bearer flow with an External Client App and a per-environment signing key. No Salesforce password is ever collected, no long-lived refresh token is stored on our side, and short-lived access tokens live in memory only.
A scoped permission set
We provide a permission set tailored to the objects, fields and tabs your in-scope processes touch. You assign it to the integration user, and nothing more. When Milita reads org structure to propose Promises she uses an API-only reader that cannot sign in or act, or the integration user with View Setup and Configuration as the fallback.
Certificate revocation is the off switch
Because access hinges on the signing certificate, you can end Milita's access to your org instantly and on your own by revoking that certificate in Setup. No tickets, no waiting on us. Removing the environment in the product stops new access; revoking in Salesforce also ends access already held.
A conversation, not a checklist.
The first thing Milita does in a new workspace is connect it to a sandbox. She explains each step, shows the Salesforce screen you are on, verifies the step the moment it is done, and picks up where you left off if you come back later. Someone who is not an admin can start and hand the admin steps to the person who holds the rights.
One button, ninety seconds of admin time
The next version performs the setup through Salesforce's own APIs after a single admin consent: signing key, External Client App with its certificate, a non-admin user proposal, a permission set sized to the processes in scope, the connection check, then a receipt of every object created with an Undo button, and the admin token discarded.
Checked again, every time.
Is it still a sandbox?
Every run and every hosted browser session confirms the org is a sandbox before any Salesforce access is issued.
Is the user still non-admin?
Each time new access is obtained from Salesforce, at most five minutes after the last, the user's permissions are read again and an admin-level user is refused.
Does the pipeline key still have the right?
API keys are scoped to starting proofs and reading results, can be limited to specific Promises, and expire.
Connect a sandbox and prove one process.
Free for 3 Promises, forever. Revoke our access any time from Setup.