October 20, 2023
Getting a solution onto Salesforce AppExchange puts it in front of buyers who are already inside Salesforce and already looking. The listing itself is a defined pipeline. You join the partner program and package the app. You build a listing page and pass a security review. You set up licensing before anything goes live.
Teams usually arrive here with a working app and no idea what happens next. The build was the part they understood. Then someone mentions a partner business org, a managed package, and a security review. The release date starts drifting, because nobody scoped the distribution work.
This guide covers the listing pipeline rather than the build. It walks the three decisions to settle first. It covers what the security review checks, how licensing works, and what the listing needs once it is live.
AppExchange is the Salesforce marketplace. Customers use it to find and install apps, components, Bolt solutions, and consulting services.
Listing is a separate track from building. Your app can be finished and still be months away from being installable by a customer.
The listing work has five parts. Partner program enrollment. Packaging your solution for distribution. Creating the listing page. Passing security review. Setting up licensing and support.
Each part depends on the one before it. That is why teams treating listing as a final step lose weeks.
Start the partner enrollment early. Nothing else can begin until it is done.
Building the app is a different project with its own decisions. Our guide on building and launching an AppExchange app covers that side in detail.
One more thing worth knowing up front. Listing is not only for products. Consulting partners list services, and component providers list smaller pieces than a full app.
The pipeline below applies to all of them. Only the depth of the security review really changes.
Settle these three before you write any distribution code. Changing them later means repackaging.
| Decision | Your Options | What It Affects |
|---|---|---|
| Partner type | ISV, OEM, consulting partner, component provider | Which agreement you sign, what you can charge, which review path applies |
| Package type | Managed or unmanaged | Whether you can upgrade customers, license the app, or protect your code |
| License model | Free, paid per seat, paid per org, freemium | Whether you need the License Management App connected before launch |
| Distribution scope | Public listing or private sharing | Whether you go through full security review |
| Trial approach | Free trial org, trial in existing org, or none | How much setup work you owe before launch |
The partner type decision drives the rest. It determines which agreement you sign, what you can charge, and which review path applies.
Package type is the one teams get wrong most. Unmanaged packages cannot be upgraded and cannot be licensed, which rules them out for most commercial listings.
License model decides whether you need the License Management App connected before launch. Adding it afterward is possible but awkward.
Write these three answers down and share them with your engineering team. Half the rework in a first listing comes from two people assuming different answers.
If you are still deciding whether to publish at all, our post on building custom versus buying from the marketplace covers that earlier question.
Work through these in order. Each step depends on the one before it.
Walkthroughs on Salesforce Tutorial are a reasonable starting point if your team has never touched the partner side of the platform.
Packaging is where a working app becomes something a stranger can install into their own org.
A managed package locks your code, protects your intellectual property, and lets you push upgrades to every customer who installed it. That upgrade path is the reason commercial apps use managed packages.
Second-generation packaging is the current approach. It uses source-driven development and version control rather than a packaging org you click through.
Your namespace prefix goes onto every component in the package and cannot be changed afterward. Pick something short and clearly yours.
Test the installed experience, not just your development org. Install the package into a clean org and walk through setup exactly as a customer would.
That clean-org install catches a whole category of problems. Hardcoded IDs, missing permission sets, and assumptions about existing data all surface immediately.
Do the uninstall too. A package that leaves debris behind when removed reflects badly, and reviewers do check.
Version your package properly from the first release. Customers will end up on different versions, and you need to know which. Technical writers like Jitendra Zaa publish useful breakdowns of the packaging mechanics. Our AppExchange app development team treats packaging as part of the build rather than a step afterward.
This is the step that decides your timeline, and it is where most first attempts get findings.
The review looks for the security problems that would put a customer org at risk. Injection flaws in dynamic queries. Missing sharing enforcement. Fields exposed without checking field-level security. Insecure endpoints and stored credentials.
It also checks your documentation against what the package really does. And it checks that a reviewer can install and use the app with the credentials you supply.
Run the static analysis tooling Salesforce provides against your package and clear the findings before you submit. Most of what a reviewer flags is catchable this way.
Expect false positives and write them up. A clear explanation of why a flagged line is safe moves faster than leaving a reviewer to work it out.
Prepare the submission properly. Give the reviewer a working test org, valid credentials, and a walkthrough document. Removing every reason to guess shortens the cycle more than anything else you do.
Community write-ups on Salesforce Codex cover the patterns that get flagged most often.
Findings are normal, not a failure. You fix them, document what changed, and resubmit.
Build resubmission time into your plan. Treating the first submission as the finish line is how launch dates slip.
Keep the same person on the review thread throughout. Context gets lost fast when the responder changes between rounds.
Read every finding literally before you argue with it. Most are narrower than they first appear.
Be careful with the numbers you find online. Published guidance on review fees and review duration varies widely, and some of it is years out of date.
Estimates for the security review alone range from a few weeks to several months across current public sources. Fee figures differ by a similar margin.
Four things drive both. Your partner type, your package complexity, whether the app is free or paid, and how clean your first submission is.
Take your actual numbers from the Salesforce partner portal and your partner account manager, not from a blog post. That includes this one.
What you can plan on is the shape. Partner enrollment, packaging, and listing creation are largely in your control. Security review is not, so leave room for at least one round of findings.
Decide early whether your app is free, paid, or freemium. That choice changes what you need in place at launch.
Paid apps need the License Management App connected to your Partner Business Org. It tracks who installed your package, how many seats they hold, and when their license expires.
Licensing also gives you the ability to suspend access when a subscription lapses. Without it you have no enforcement, only an invoice.
Trial provisioning is worth setting up at the same time. A buyer who can try your app in a working org converts far better than one reading a description.
Decide your support commitment before launch too. Response times appear on your listing, and buyers compare them.
Support load scales with installs, not revenue. Free tiers generate real tickets, so plan for that before you offer one.
The listing page is your storefront, and most of them undersell the product.
| Listing Element | What Good Looks Like | The Common Mistake |
|---|---|---|
| Title | The outcome a buyer gets, in plain words | Your internal product codename |
| Short description | One line naming the problem you solve | A feature list with no problem in it |
| Full description | Written for an admin who has never heard of you | Company history before product value |
| Screenshots | Current interface, real data, readable at thumbnail size | Retired UI, placeholder data, tiny text |
| Demo video | Problem, fix, stop. Short | A recorded webinar nobody finishes |
| Supported editions | Exactly which editions and clouds work | Vague claims that generate refund requests |
| Pricing | Clear tiers and what each includes | Contact us as the only option |
| Support details | Response times you can actually hold to | Promises the team cannot meet |
Write the description for a Salesforce admin who has never heard of you. Lead with the problem you solve, not your company history.
Reviews carry real weight in this marketplace. Ask your early customers directly, because very few leave one unprompted.
Keep your screenshots current. Nothing dates a listing faster than an interface Salesforce retired two releases ago.
A short demo video usually outperforms a long one. Show the problem, show the fix, and stop. Browsing the top AppExchange apps is a quick way to see how established providers handle their listing pages.
Publishing is the start of the maintenance commitment, not the end of the project.
Salesforce ships three platform releases a year. Test your package against each preview release, because a change that breaks your app breaks it for every customer at once.
Push upgrades let you update installed packages without customer action. Use them carefully, test them thoroughly, and tell customers what changed.
Watch your listing analytics and your review page. Both tell you where buyers drop off, and both are easier to act on than survey data.
Keep your provider profile and documentation current. A listing referencing a Salesforce feature by a retired name signals a product nobody is maintaining.
Set a quarterly review of the listing itself. Copy, screenshots, supported editions, and pricing all drift out of date quietly. Release-readiness guidance on Salesforce Admins is worth following for the preview-release calendar.
Salesforce has added AgentExchange, a companion marketplace for Agentforce agents and agent actions.
Publishing an agent or an agent action is different from publishing an app. Check which marketplace applies, and which review path, before you build a distribution plan.
Product naming across the platform has shifted too. Einstein branding moved to Agentforce, Data Cloud is now Data 360, and Pardot is Marketing Cloud Account Engagement.
Those names matter for your listing copy. A description using retired product names dates your solution in the eyes of exactly the buyers who know the platform best.
We treat listing as a distribution engineering problem, not a paperwork exercise. The package, the licensing, and the review evidence all get designed before submission. Nothing gets assembled after a rejection.
Our engineers run the static analysis and the clean-org install themselves. Then they write the reviewer documentation from what the package really does. That combination turns a multi-round review into a short one.
We also build the post-launch mechanics in from the start. License enforcement, trial provisioning, and a tested push-upgrade path ship with the first release. None of it becomes a later project.
When we take over a stalled submission, the first step is usually reading the findings properly. Most rejections point at a small number of patterns that repeat across the package.
Yes. Partner program enrollment comes first, and nothing else in the pipeline can start until your Partner Business Org exists.
A managed package protects your code and supports versioning, upgrades, and licensing. An unmanaged package is a one-time copy. It cannot be upgraded or licensed, which rules it out for commercial listings.
It varies widely by partner type, package complexity, and submission quality. Public estimates disagree a lot. Confirm current guidance through the partner portal rather than a third-party article.
Yes, and many providers start there to build reviews and adoption before introducing paid tiers. Requirements still apply, including the security review.
Your package must keep working across three platform releases a year. Test against each preview release and use push upgrades to keep installed customers current.
Listing on Salesforce AppExchange rewards teams that treat distribution as engineering work. Partner setup, packaging, licensing, and review evidence all need designing. The steps that slip are the ones nobody scoped. Settle your partner type, package type, and license model first, and the rest follows in order.
Minuscule Technologies approaches this as Salesforce engineering partners rather than listing consultants. Our engineers package the solution and run the security tooling themselves. They write the reviewer documentation and build license enforcement before anything gets submitted. That preparation is what keeps one review from turning into three.
What you get back is a listing that installs cleanly and a licensing setup that enforces. The upgrade path survives three platform releases a year. Book a free strategic call with our AppExchange engineers and we will map your listing plan against where your app is today.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
