Test Drive
A Test Drive is an AppExchange feature that lets a prospective customer explore a partner's app inside a shared, preconfigured org, without installing anything.
Definition
A Test Drive is an AppExchange feature that lets a prospective customer explore a partner's app inside a shared, preconfigured org, without installing anything. The customer clicks one button on the listing and lands in a read-only demo environment, signed in automatically as an evaluation user.
Test Drives sit alongside free trials as a low-commitment way to evaluate a managed package. They show the app in action with realistic sample data, so a buyer can judge the product before talking to sales or installing it in their own org.
How a Test Drive works on AppExchange
What a Test Drive actually is
A Test Drive is one of the evaluation paths an ISV partner can offer on an AppExchange listing. When a visitor clicks the test drive button, AppExchange transports them into a shared org that the partner has set up in advance. The app is already installed, sample data is already loaded, and the visitor is logged in as a generic evaluation user with no password of their own. The point is speed and zero friction. The customer does not install a package, does not spin up a trial, and does not touch their own Salesforce data. They get a guided look at functional pages and prepopulated records, then a path to contact the sales team when they are ready. Salesforce describes the test drive as the easiest way to show an app to people who do not even use Salesforce yet, which makes it useful for early-stage buyers and non-admin stakeholders who just want to see the thing run.
The shared, read-only org
The defining trait of a Test Drive is that everyone shares one org. Every prospect who clicks the button logs into the same environment as the same evaluation user. Because many people can be inside at once, the data has to be protected. Salesforce makes the evaluation user read-only, so customers cannot change any of the data in the org, and they do not need a password to get in. This read-only design is what separates a Test Drive from a free trial. A trial gives each prospect a fresh, fully editable org of their own. A Test Drive trades that isolation for instant access and no setup. The buyer can click around, open records, and run reports, but they cannot create or edit data that would leak into the next visitor's session. For a partner, that means the demo always looks the way it was staged, no matter how many people pass through it.
Test Drive versus free trial
AppExchange gives partners two main hands-on options, and they solve different problems. A Test Drive is read-only, shared, and instant. A free trial is editable, private, and closer to a real install. Many listings offer both so the buyer can choose how deep they want to go. Use a Test Drive when you want the lowest barrier to a first look, especially for prospects who are not Salesforce admins and would struggle to install anything. Use a free trial, often built with a Trialforce template, when the prospect wants to configure the app, load their own scenarios, or test integrations in an org they control. A common pattern is to lead with a Test Drive for the casual evaluator, then hand serious buyers a trial. The two are complementary, and offering both signals that you are confident enough to let people drive the product themselves.
The evaluation user and profile
Behind the scenes, the access in a Test Drive org is controlled by a dedicated evaluation user tied to a restricted profile. Salesforce guidance points you to edit the evaluation user and confirm that a test drive evaluation profile is assigned. The goal is to give that user only the access they need: read-only access to the test drive org and minimal access to objects. This matters for two reasons. First, it keeps the demo safe when strangers are logged in as that user. A misconfigured profile that grants edit or delete could let a visitor break the staged experience for everyone after them. Second, it shapes what the buyer sees. Tabs, fields, and records the evaluation user cannot read simply will not appear, so the profile doubles as a curation tool. Set it carefully and the test drive shows exactly the slice of the app you want a first-time visitor to experience, and nothing that would confuse or distract them.
Setting up the org and listing
A Test Drive org usually starts from a Trialforce template created through Environment Hub. The partner provisions the org, installs the managed package, loads sample data, and configures the evaluation user and profile. Once the org behaves the way the demo should, the partner connects it to the listing. There is an order of operations to respect. Before you can offer a test drive, a managed package for your solution must be linked to the listing. With that in place, you open the AppExchange Partner Console, go to your listing, find the test drive settings, and toggle the option on. You then supply the test drive org ID along with the evaluation user's username and password so AppExchange can log visitors in automatically. From that moment, the button appears on your public listing and prospects can start exploring with a single click.
Security review and what is exempt
AppExchange has a mandatory security review for any managed package application that gets listed, because that code can run in customer production orgs. Test Drives are treated differently. The test drive app and org do not need to be security reviewed, since they are never deployed into a customer's production org and hold no customer data. That carve-out is worth understanding precisely. It does not exempt your product from review. The managed package you list still goes through the normal security review process. What the exemption covers is the staged demo environment itself, the shared org behind the test drive button. Because that org is yours, read-only, and isolated from any buyer's real data, Salesforce does not put it through the same scrutiny as installable code. So the review effort stays focused on the package, while the test drive remains a fast way to let people look without adding review overhead.
How to set up an AppExchange Test Drive
Offering a Test Drive means staging a shared demo org and connecting it to your AppExchange listing through the Partner Console. Link your managed package to the listing first, then enable the test drive and point it at your evaluation org.
- Build and stage the test drive org
Create the org from a Trialforce template in Environment Hub, install your managed package, and load realistic sample data that shows the app at its best.
- Lock down the evaluation user
Edit the evaluation user, confirm the test drive evaluation profile is assigned, and grant only read-only access so visitors can look but never change the staged data.
- Link the managed package to your listing
In the Partner Console, make sure a managed package for your solution is associated with the listing, since a test drive cannot be enabled without one.
- Enable the test drive on the listing
Open the listing in the Partner Console, find the test drive option, toggle it on, and provide the test drive org ID with the evaluation user's username and password.
- Publish and test the button
Save and publish, then click the test drive button on your live listing yourself to confirm visitors land in the right org as the evaluation user.
The org ID of the shared demo environment AppExchange logs visitors into when they click the button.
The username and password of the read-only evaluation user; AppExchange uses these to sign every visitor in automatically.
The restricted profile assigned to the evaluation user that defines read-only access and which tabs, objects, and records appear.
The packaged solution tied to the listing; required before the test drive option can be turned on.
- A test drive is read-only and shared, so never rely on it to demo create or edit flows; use a free trial for editable scenarios.
- Anyone clicking the button shares one org, so a profile that allows edits could let a visitor break the demo for everyone after them.
- You must link a managed package to the listing before the test drive option becomes available.
- The test drive org is exempt from security review, but the managed package you list still has to pass the normal review.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Test Drive.
Hands-on resources to go deeper on Test Drive.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Test Drive?
Q2. Does it affect your production org?
Q3. Who configures the trial?
Discussion
Loading discussion…