Salesforce AppExchange: the security review and listing playbook

Listing on a large CRM marketplace can put your product in front of buyers who are already in the system where they work. It can also turn into a months-long detour with a security review you were not ready for and a listing nobody clicks. Salesforce AppExchange is one of the biggest of these marketplaces, and the difference between those two outcomes is mostly preparation: knowing whether it fits before you start, building on the right surface, treating the security review as acceptance criteria rather than a surprise, and writing a listing that earns the install.

This is an independent playbook. PartnerMatch is not affiliated with Salesforce, and nothing here is an official program document. Marketplace requirements change, so treat the exact criteria, timelines, and program names as things to confirm in the current official documentation rather than as fixed facts. What does not change much is the shape of the work, and that shape is what this guide covers: the decision, the build, the review, and the listing, in the order you hit them.

It pairs with our broader SaaS marketplace strategy guide and our walkthroughs of other ecosystems, like the HubSpot App Marketplace and the Shopify app playbook, so you can compare what is common across marketplaces and what is specific to this one.

The 60-second version

• Decide fit first. AppExchange pays off when your buyers already live in the CRM and your product clearly extends their work there. If that is not true, the effort may not return.
• Build on the platform's APIs, not around them. The cleaner your integration with the host's data and auth model, the smoother every later step goes.
• The security review is the gate. Treat its requirements as acceptance criteria you build against from day one, not a checklist you scramble through at the end.
• Prepare evidence, not just code. Reviewers want to see least privilege, secure data handling, and traceability, with documentation to back it.
• A listing is a conversion surface. Lead with the workflow and outcome, show real screenshots, and make pricing and support clear.
• Listed is the start, not the finish. Installs come from activation, reviews, and the work after launch, not from the listing existing.
• Confirm the specifics officially. Names, criteria, and timelines shift, so verify against current documentation before you commit a roadmap.

Step 1: decide whether AppExchange fits

The most expensive mistake is doing all of this work for a marketplace that was never going to move your numbers. Before any build, answer one question honestly: are your buyers already inside this CRM, and does your product extend the work they do there?

When the answer is a clear yes, a marketplace listing meets customers where they already are. A team standardized on the CRM would rather add a capability from inside it than evaluate a separate tool, and "available on AppExchange" is a trust signal to a cautious buyer. When the answer is no, when your users do not live in the CRM, or your product only loosely touches it, the listing becomes a vanity placement that costs months and returns little.

Work through the fit before you commit:

If most of your answers land in the right column, the honest move is to hold off and revisit when the fit is stronger. We work through this kind of decision in detail in build, buy, or partner and our marketplace strategy guide. A listing is worth real effort only when there is a genuine workflow and real customer pull behind it.

Step 2: build on the platform's APIs

Once you have committed, the build determines how hard everything after it will be. The principle is to integrate with the platform's own data model, authentication, and extension points rather than working around them. An integration that respects the host's conventions is easier to build, easier to review, and easier for the customer to trust.

In practice this means a few things. Authenticate the way the platform expects, using its standard authorization flows rather than asking customers for credentials you store yourself. Read and write data through the documented APIs, mapping to the platform's objects instead of inventing a parallel structure. Request only the access your features actually use, because every extra permission is something the customer and the reviewer will question. And handle the platform's data with the same care as your own, because once you read a customer's CRM records you are responsible for them.

The patterns underneath this are the same ones in any solid integration: clean authentication, scoped permissions, reliable sync. Our guide to a partner-ready API covers the producer side, and webhooks vs polling covers keeping two systems in sync without missing changes or hammering the platform. The better you follow the platform's grain here, the less friction you hit at the review, because most review findings trace back to an integration that took shortcuts around the intended model.

Step 3: treat the security review as acceptance criteria

This is the step that surprises teams, and it is the one that decides your timeline. A marketplace that puts apps in front of enterprise buyers reviews those apps before they list, and that review is a real gate, not a formality. The mistake is treating it as a final exam you cram for. The right move is to treat its requirements as acceptance criteria you build against from the first commit.

The reasoning is simple. Security findings discovered at the end are expensive, because fixing them often means changing how the app handles data or permissions, which is rework on top of finished features. The same findings caught during the build are cheap, because you build it right the first time. So you read the current security requirements before you design, fold them into your definition of done, and verify against them as you go. This is the same logic as our guide to app certification without the pain: the checklist is acceptance criteria, and meeting it should be a non-event because you have been building to it all along.

The exact requirements are the platform's to define and they change, so confirm them in current official documentation. The categories reviewers care about are stable across serious marketplaces:

Two practices make the review go smoothly. First, prepare evidence, not just working code. Reviewers want to see how you handle data and why your permissions are scoped the way they are, which means documentation, not just a passing demo. Second, do a self-review against the published requirements before you submit, ideally with someone who did not build the feature, so the obvious gaps get caught by you instead of by the reviewer. A clean first submission saves a round trip, and round trips are where weeks go. For the deeper engineering side of this, common web and API vulnerability classes are well documented by OWASP, linked at the end.

Step 4: write a listing that converts

Passing the review gets you the right to list. It does not get you installs. The listing is a conversion surface, and most of them undersell the product by describing what it is instead of what it does for the person reading.

Lead with the workflow and the outcome. A buyer scanning the marketplace is asking one question: will this make a job I already do faster or better. Answer it in the first lines, in their language, before any feature list. "Keep your CRM contacts in sync with X automatically" beats "a powerful integration platform" every time, because the first names a job the buyer recognizes and the second makes them work to figure out if it applies.

What a listing that converts includes:

• A workflow-first headline and summary. The outcome and the job, in the buyer's words, not your internal product name for the feature.
• Real screenshots. Show the integration doing its job inside the platform. A buyer wants to see what they are getting, and a real screen beats a stock graphic.
• Specific value, not adjectives. "Syncs in real time so reps never work from stale data" tells them something. "Streamlined and powerful" tells them nothing.
• Honest, clear pricing. Whatever your model, state it plainly. A buyer who cannot tell what it costs assumes the worst and moves on.
• Social proof. Reviews, ratings, and named customers if you have them. Early on, even a handful of genuine reviews moves the needle.
• Obvious support. Make it clear that someone is behind the app and how to reach them. Enterprise buyers will not install software with no visible owner.

We go deeper on this in our guides to writing a marketplace listing that converts and how marketplaces rank apps. The short version: the listing is sales copy aimed at a specific buyer doing a specific job, and the ones that convert are the ones that name that job and prove the app does it.

Step 5: drive installs after you list

A common assumption is that listing is the finish line and installs follow on their own. They do not. A new listing in a large marketplace is one tile among many, and discovery alone will not carry it. The work after launch is what turns a listing into pipeline.

The first turn of the flywheel is the hardest, so prime it deliberately. Point your own customers who use both products at the listing to seed the first installs. Ask happy customers for honest reviews, because the first few reviews are what make the next buyer comfortable. Then watch what happens after install: the metric that matters is not installs, it is active, retained connections, and a customer who installs but never activates is a churn risk, not a win.

The motions that drive adoption after launch:

We cover the post-launch playbook in driving installs after launch and the wider motion in our co-selling engine guide. The throughline is that the listing is the start of the work, not the end of it.

Common mistakes, and the fix

Listing because the marketplace is big, not because it fits. The fix: confirm your buyers live in the CRM and your product extends their work there before you commit. A listing without genuine fit and customer pull is months of effort for a tile nobody clicks.

Treating the security review as a final exam. The fix: read the current requirements first and build against them as acceptance criteria. Findings caught during the build are cheap; findings caught at submission are rework on finished features, and that is where timelines slip.

Requesting more access than you use. The fix: scope permissions to exactly what your features need. Every extra permission is something the customer hesitates over and the reviewer questions, and least privilege is both safer and easier to approve.

A listing that describes the product, not the job. The fix: lead with the workflow and outcome in the buyer's language, show real screenshots, and make pricing and support clear. The buyer is asking whether it helps a job they already do; answer that first.

Assuming installs follow the listing. The fix: seed the first installs from existing customers, gather reviews, instrument activation, and follow up on stalled installs. Discovery alone will not carry a new tile in a crowded marketplace.

FAQ

Is this an official Salesforce guide? No. PartnerMatch is independent and not affiliated with Salesforce, and this is not an official program document. Use it to understand the shape of the work, and confirm the exact requirements, timelines, and program names in the current official documentation, which can change without notice.

How long does listing on AppExchange take? It depends on your starting point and how much rework the security review surfaces, so a build that already follows the platform's model and meets the published security requirements moves faster than one that took shortcuts. The single biggest variable is how prepared you are for the review, which is why building against its requirements from the start is the best way to compress the timeline.

What does the security review actually check? The exact criteria are the platform's to define and they change, so confirm them officially. The categories are stable across serious marketplaces: least-privilege access, secure authentication, secure data handling and isolation, absence of common vulnerabilities, proper secret management, and clear documentation. Treat those as acceptance criteria you build to, and prepare evidence, not just working code.

Do we need to be a Salesforce partner to list? Marketplace participation typically involves a partner relationship and program steps that the platform defines and updates, so confirm the current requirements in official documentation rather than assuming. The work in this guide, fit, build, review, and listing, applies regardless of the exact program structure on the day you start.

How do we get installs after listing? Not from the listing existing. Seed the first installs from customers who already use both products, gather honest reviews to build social proof, instrument activation so you can see who installed but never connected, and follow up on the stalled ones. A new listing is one tile among many, and the post-launch work is what turns it into pipeline.

How is this different from listing on other marketplaces? The shape is the same across serious marketplaces: decide fit, build on the platform's model, pass a review, write a converting listing, and drive installs after launch. The specifics differ in the exact security requirements, partner program, and listing format. Comparing our HubSpot and Shopify playbooks against this one shows what is common and what is platform-specific.

Further reading

• Salesforce AppExchange to see the marketplace itself and how listings are presented to buyers.
• Salesforce Partners for the official partner program information, which is where to confirm current requirements and steps.
• OWASP for the common web and API vulnerability classes a security review tests for, useful on the engineering side of preparing for review.

The short version

Listing on Salesforce AppExchange is worth real effort when your buyers already live in the CRM and your product clearly extends their work there, and a costly detour when that fit is missing. Build on the platform's own APIs, auth, and data model instead of working around them, because most review findings trace back to shortcuts. Treat the security review as acceptance criteria you build against from day one, not a final exam, and prepare evidence of least privilege, secure data handling, and isolation rather than just a passing demo. Write a listing that leads with the workflow and outcome, shows real screenshots, and makes pricing and support clear. Then do the post-launch work, seed installs, gather reviews, and instrument activation, because the listing is the start of the work, not the end. And because marketplace specifics change, confirm the exact criteria and program steps in current official documentation, since this is an independent playbook, not an official one.

If you want help deciding whether a marketplace fits, preparing for the review, or turning a listing into pipeline, a Partner Audit reviews your product, your integration surface, and your marketplace potential, then hands you a concrete plan for what to build and which ecosystems to pursue.