Spin up a Partner Developer Edition from the Environment Hub, install the exact Managed-Released version you are submitting, and connect it to a reviewer account in your own product. That org is the test environment. The ISVforce Guide says "The security review team uses the Developer Edition org as the solution test environment," and its Product Security team uses it to hunt for vulnerabilities, not to check that your features work. A sandbox, a scratch org or your packaging org won't do.
For a SaaS company, the test org is where the native integration enterprise customers asked for meets its first adversarial user. You build the package, pass review, publish the listing, then keep shipping versions that inherit the review. A submission can come back before any tester opens it, over the org itself. Salesforce lists a wrong package version and expired credentials among its verification feedback, and it estimates verification at 1 to 2 weeks each time. Appnigma's marketplace apps service covers this path, with "Salesforce security review preparation and responses" included. If you came for sandboxes and test environments for your own Salesforce org, Salesforce's sandboxes page is the better start.
Updated October 2026. Checked against the Salesforce ISVforce Guide and the Salesforce DX Developer Guide. The earlier version said the review checks functionality and performance and pointed to an org page on our platform that no longer exists. This update corrects both. It also adds which org types qualify, what has to be installed, and what reviewers need outside Salesforce.
Which org Salesforce accepts as the test org
Salesforce asks for a Developer Edition org, and the submission page says to "Configure a Developer Edition test environment with your solution installed." ISV partners can get a Partner Developer Edition, which is a Developer Edition with higher limits, from the Environment Hub in their Partner Business Org. The REST API access page says "you can get the Partner Developer Edition from the Environment Hub."
How long each candidate org lives matters more than most teams expect, because the org has to stay reachable for the whole review.
| Org | Use it as the test org? | How long it lives |
|---|---|---|
| Partner Developer Edition (Environment Hub) | Yes, the usual choice for partners | Never expires, per the Environment Hub FAQ |
| Developer Edition (free signup) | Yes | Can expire from inactivity, per the Dev Hub setup page |
| Packaging org or Dev Hub | No, verification sends it back | Your long-lived build org |
| Test/Demo trial org (Enterprise, Professional, Group) | Not what Salesforce asks for | 30 days |
| Scratch org | Not what Salesforce asks for | 1 to 30 days, per the Scratch Orgs page |
The lifespan column is where a short-lived org fails. Salesforce's typical time frames are 1 to 2 weeks for verification and 3 to 4 weeks for the first test. Worked from those estimates, a first pass can run 6 weeks, and one resubmission adds 2 to 3 more, so the org may need to stay up for about 9 weeks. A 30-day org would expire partway through. A free Developer Edition works, but the docs warn that "Developer Edition orgs can expire due to inactivity," and a test org sits idle on your side for weeks. The Partner Developer Edition never expires, which is why it is the safe default.
The packaging org row is the mistake Salesforce names directly. Its verification feedback page lists "Perhaps you submitted a packaging org instead of a test org" as a reason a submission comes back. Keep the org where you build and the org reviewers attack separate. It also keeps reviewers away from your source and namespace settings.
What has to be installed in the test org
The package in the org must be the exact version you submit, released and managed. The Required Materials page asks for a Managed-Released package and says "We can't accept an unmanaged or beta package." The same verification page flags a test org that "contains a different package version than the one you submitted." For a second-generation package (2GP) this also settles the order of work. The promote page says "Beta versions can be installed in only scratch orgs and sandboxes," so a 2GP beta can't even go into a Developer Edition. Promote the version, install that version in the test org, and only then start the wizard.
Install everything a customer would install. If your package is an extension, the Required Materials page says to "install all base and dependent packages for the solutions that your package extends or integrates," even when those base packages already passed review. Then configure the org so a reviewer can use the product the way a customer does. That means the package's permission sets assigned to the login user, the integration connected to your service, and enough records for every page to load.
Reviewers test whatever they can reach. The Test Your Entire Solution page says they "can perform pen tests that attack your Developer Edition test org and attempt to access sensitive data or authenticate with false credentials." An org where half the features are switched off doesn't make review easier. It makes the reviewer guess, and a guess often ends in a question that adds time.
Your service is part of the test environment too
For a SaaS integration, the Salesforce org is only half of what reviewers test. Salesforce scopes the review with a "follow-the-data approach." The Required Materials page says to "Provide access to all environments, packages, and external components that your solution uses." For a solution with an external web app or service, its table adds "URLs and login credentials for external components requiring authentication" and DAST scan reports for those endpoints.
In practice your test environment is the Developer Edition org plus a working account in your product that the org is already connected to. Give reviewers an account they can log in to, on the environment your scans covered. If customers connect through OAuth, finish that connection in the test org before you submit, so reviewers see the real token flow rather than a setup screen. Our guide to the web application scanner the review needs covers which hosts to scan and how.
Credentials are the part that goes stale. The verification page lists "expired authentication credentials or an invalid access URL for a web app or service" as a standard reason a submission is returned. The wizard's Provide Environments step takes a username and password, and Trailhead's submission unit says "The form verifies authentication by logging into the org." Use a dedicated reviewer account that no one rotates during the review, and don't put it behind a password that expires in 30 days. If it does go stale, the review stages page says "There's no charge to resubmit a returned submission," but you lose the weeks.
Does the security review test whether your app works?
No. Salesforce describes the review as a security test. The ISVforce Guide says "our Product Security team attempts to identify security vulnerabilities in your solution." Functional quality, performance and user experience are yours to test. The test org exists so reviewers can probe sharing, CRUD and field-level security, injection and authentication, not so they can sign off on features.
That changes how you prepare the org. Reviewers need access to every surface that touches data, including admin settings pages and Lightning components that only power users see, not a polished demo path. The review is also "a black-box, time-limited process," so a failed report lists representative issues rather than every instance. Fix the pattern across the whole package before you resubmit.
Once a version passes, you rarely need a new test org. The listing readiness page says later versions built on a passed ancestor don't have to be submitted. Skipping that submission is what saves "time, resources, and security-review fees." The ISVforce Guide adds that with patches "security review inheritance is limited," so submit major and minor versions. Keep the Partner Developer Edition anyway, since any version you do submit needs a test org with that version installed.
Mistakes that send the test org back at verification
Each of these gets a security review submission returned at verification, before any tester opens the org, and each one costs a round.
- Submitting the packaging org or Dev Hub. Salesforce names it as a verification failure.
- A beta or older version in the test org. The installed version has to match the submitted Managed-Released version.
- A short-lived org. A scratch org, a 30-day trial or an idle Developer Edition can expire before testing starts.
- Reviewer credentials that expire or need a code sent to your phone. Reviewers can't log in, and the submission comes back.
- The integration not connected. Reviewers see a setup page and can't reach the code that moves Salesforce data.
- Base packages missing for an extension. Salesforce asks for every base and dependent package, reviewed or not.
- The test org reused for demos. Someone changes a password or uninstalls a version mid-review. Give the review its own org.
Frequently Asked Questions
Can I use a sandbox as the security review test environment?
Salesforce's review docs ask for a Developer Edition org and never name a sandbox as an option. ISV partners usually create a Partner Developer Edition from the Environment Hub, which never expires.
Can I submit my packaging org for the security review?
No. Salesforce lists "submitted a packaging org instead of a test org" as a reason it returns a submission at verification.
Can the test org have a beta package installed?
No. Salesforce accepts only a Managed-Released package, and the test org must hold the same version you submit.
Do Marketing Cloud apps need a test org?
No. Salesforce says the Developer Edition org and documentation "aren't required for Marketing Cloud apps," which submit credentials to the Marketing Cloud environment instead.
Can Appnigma set up the test environment and handle the review for us?
Yes. Appnigma's marketplace apps service builds the native app and includes "Salesforce security review preparation and responses." Approval timing stays with Salesforce.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- The Salesforce security review guide for SaaS teams
- The AppExchange security review, step by step
- Which web application scanner the security review needs
- How to prepare your managed package for security review
- How long the Salesforce security review takes
- What Dev Hub in a Partner Business Org is for
- Salesforce security review checklist
Sources
- Salesforce Developers, ISVforce Guide, How the AgentExchange Security Review Works
- Salesforce Developers, ISVforce Guide, Submit Your Solution for AgentExchange Security Review
- Salesforce Developers, ISVforce Guide, Required Materials for Security Review Submission
- Salesforce Developers, ISVforce Guide, Feedback About Submission Verification
- Salesforce Developers, ISVforce Guide, Test Your Entire Solution
- Salesforce Developers, ISVforce Guide, What kinds of orgs can I create in the Environment Hub?
- Salesforce Developers, ISVforce Guide, Accessing REST API in Group and Professional Editions
- Salesforce Developers, Salesforce DX Developer Guide, Scratch Orgs
- Salesforce, Sandboxes and Environments
- Salesforce Developers, ISVforce Guide, AgentExchange Security Review Stages
- Salesforce Developers, ISVforce Guide, Listing Readiness for Managed Packages
- Salesforce Developers, Second-Generation Managed Packaging, Get Ready to Promote and Release a Second-Generation Managed Package Version
- Salesforce Developers, Salesforce DX Developer Guide, Select and Enable a Dev Hub Org
- Trailhead, ISV Security Review, Submit Your Solution
