So You Want to Publish on AppExchange? Here's What Nobody Tells You.
Building a Salesforce app was 40% of the work. The other 60% was everything that comes after: namespaces, packaging, security reviews, and a lot of waiting. This is the honest guide to AppExchange publishing.
You've built something useful. A Salesforce app that solves a real problem. You've tested it, deployed it, used it yourself. It works.
Now you want to share it with the world. Put it on AppExchange. Let other orgs install it. Maybe even build a business around it someday.
How hard can it be?
That's what we thought when we decided to list our user access audit tool on AppExchange. We had a working product. Solid code. Good documentation. We figured the hard part was behind us.
We were wrong.
Building the product was maybe 40% of the work. The other 60% was everything that comes after: packaging, namespaces, security reviews, partner enrollment, and a lot of waiting for Salesforce to respond to anything.
This post is the guide I wish I'd found before we started. No fluff. Just what actually happens when you try to get your app onto AppExchange.
The Starting Point
The Moment You Decide to Go Public
There's a specific moment every AppExchange publisher remembers. You're looking at your app, and you think: "Other people need this too."
For us, it was a compliance automation tool. We built it internally because the manual process was painful and repetitive. When we showed it to colleagues at other companies, the reaction was always the same: "Can we have that?"
So we decided to package it up and put it on AppExchange. Simple enough, right?
Here's what we didn't know: the gap between "working app" and "AppExchange-listed product" is enormous. Not because the technical work is impossibly hard, but because nobody tells you about the process in enough detail to actually prepare for it.
The distance between "it works" and "it's on AppExchange" is bigger than you think.
The Real Timeline
What the Process Actually Looks Like
Every guide says "submit your app and wait for approval." Here's what that actually means, step by step, with realistic timelines based on our experience.
That's right. Even if your code is perfect and your documentation is flawless, you're looking at two to three months from submission to publication. The security review alone is 4-6 weeks, and that's if you pass on the first attempt.
Choosing your namespace is a one-way door. Pick wisely.
Decision #1The Namespace: A Decision You'll Live With Forever
This was the first thing that caught us off guard. Before you can create a managed package, you need to register a namespace prefix. And once you register it, you can never change it.
Your namespace shows up everywhere. In SOQL queries. In API calls. In your customers' Apex code. If you choose myns, every custom object becomes myns__Object_Name__c. Every field becomes myns__Field_Name__c.
- Keep it short. Every character adds to every API name your customers will ever type. 3-6 characters is the sweet spot.
- Register in a separate Developer Edition org. Not your Dev Hub. Not your sandbox. A dedicated DE org that exists solely to hold the namespace.
- Wait 15-20 minutes after registration before linking it to your Dev Hub. Rush it and you'll get cryptic "invalid client ID" errors.
- My Domain must be deployed on both the DE org and the Dev Hub before linking will work. The documentation mentions this, but it's easy to miss.
- Allow browser popups. The linking process uses an OAuth popup. If your browser blocks it, the linking fails silently. No error message. Just nothing happens.
The security review waiting room. Bring a book. Or three.
The Big WaitThe Security Review: Thorough, Confusing, and Slow
The security review is mandatory for every AppExchange listing. This makes sense. Salesforce is protecting its customers. We respect that.
What we didn't expect was the confusion around fees and the near-total silence during the review process.
The Fee Confusion
When we started researching, we found conflicting information everywhere. Some posts mentioned a $2,700 security review fee. Others said it was free for free apps. Salesforce's own documentation wasn't always clear.
If your app is free on AppExchange, the security review itself costs $0. You don't pay a fee for the review.
The fee that gets mentioned online ($2,700 or similar) was historically associated with paid app listings. The policies have changed over time, which is why you find contradictory information.
Our advice: check the current Partner Program terms directly before planning your budget. Don't rely on blog posts from 2023.
The Silence
This was the hardest part. You submit your app, and then... nothing. For weeks.
No progress updates. No "we've started reviewing your app." No estimated timeline. Just a status that says "In Review" and an inbox that stays empty.
"We submitted on a Tuesday. By the following Friday, we'd heard nothing. By the end of week two, still nothing. We started wondering if our submission had disappeared into a black hole."
When feedback does arrive, it's thorough. The reviewers know what they're looking at. They'll call out specific line numbers, explain the vulnerability, and tell you exactly what to fix. The quality of the review is excellent.
It's just the communication gap between submission and feedback that's painful. If Salesforce added a simple progress indicator or weekly status email, the experience would improve dramatically.
Tips for Surviving the Security Review
with sharing on every class. Check CRUD with Schema.SObjectType before DML. Use USER_MODE and stripInaccessible() where they work, but test them in a namespaced scratch org first — they can break in 2GP managed packages.The Biggest Gotcha
The Flow Trap: Why We Rewrote Everything in Apex
This one hurt. And we didn't see it coming until we were already deep into the build.
When we started, we used Flows for core business logic. This felt like the obvious choice. Salesforce promotes Flows everywhere -- "Clicks not code." Every Trailhead module and admin guide pushes you toward declarative automation.
So we built three business processes as Flows. SLA status calculations. Remediation due dates. Audit finding rollups.
They worked beautifully in our dev org. Then we learned something that made us stop and rethink the entire architecture.
Flows are completely visible inside a managed package.
When a customer installs your managed package, they can open Setup, navigate to Flows, and read every decision node and formula you wrote. Your entire business logic is laid out in a nice visual diagram for anyone to inspect, copy, or rebuild from scratch.
Apex code? Obfuscated. Salesforce compiles your Apex into bytecode in managed packages. Customers can see class names and public method signatures, but the actual logic -- the part that makes your product unique -- is invisible. That's actual IP protection.
Same business logic, completely different exposure levels. This distinction matters if your logic is what makes your product worth paying for.
But IP exposure was just the start. The deeper we dug, the worse it got.
- Flows expose your intellectual property. Every decision node, formula, and variable is readable by anyone who installs your package. A competitor could open Setup, study your logic, and rebuild it without reverse-engineering a single line of code.
- Flows can never be removed from a managed package. Once a Flow ships in any package version, it's there permanently. You can deactivate it, but you cannot delete it. Ship a bad Flow in v1.0? Congratulations, it will haunt your package metadata for the rest of its life.
- Flows don't count toward code coverage. Salesforce requires 75% Apex code coverage for managed packages. Flow logic contributes zero to that number. If half your business logic is in Flows, you're building twice the functionality but only the Apex half counts toward your coverage threshold.
- Flow XML destroys version control. A simple five-node Flow generates hundreds of lines of XML. Reviewing diffs in pull requests is nearly impossible. When two people touch the same Flow, merge conflicts are brutal and error-prone.
- Testing Flows programmatically is painful. Unit testing Apex is clean and direct. Testing a Flow means either running it through the API with elaborate setup, or building test scenarios that trigger the Flow indirectly and hoping the right path executes. There's no Flow equivalent of
Assert.areEqual().
What We Did About It
We converted all three Flows to Apex. SLA status calculations, remediation due date rules, audit finding counts -- all moved into @InvocableMethod service classes with full test coverage.
The conversion took two days. Two days we could have saved entirely by starting with Apex from the beginning.
If you do want Flows in your managed package, use them as thin wrappers only. The Flow handles the trigger event and calls an @InvocableMethod Apex class that contains all the actual logic. The Flow becomes a simple three-node diagram -- start, call Apex, end. Nothing proprietary is exposed.
But honestly? After going through this, our recommendation is simpler: skip Flows entirely for managed packages. Use Apex triggers, schedulable classes, and Lightning Web Components. You get proper test coverage, clean version control, and your IP stays hidden.
Save Flows for the things they're genuinely great at: letting your customers build their own automations on top of your package, using the @InvocableMethod endpoints you expose.
"Salesforce tells you to use Flows for everything. That advice stops working the moment you ship a managed package -- and nobody updates the guidance."
Free gets your foot in the door. Premium earns its place once trust is built.
StrategyWhy We Started Free (and When We'll Go Premium)
We could have launched with a price tag. The product is solid and it solves a real problem. But we chose to launch free, and here's why.
When you're a new publisher with zero reviews and zero installs, nobody is going to pay for your app. They don't know you. They can't see testimonials. They have no reason to trust that your product will be maintained in six months.
Free removes every barrier. No procurement process. No budget approval. No risk assessment. Just install and try it.
Free first builds the trust that makes paid tiers viable later.
- Zero adoption friction for new users
- Builds install base and social proof fast
- AppExchange reviews come from real users
- Feedback reveals what's actually worth paying for
- Competitors can't undercut "free"
- After 50+ installs prove demand
- After real users tell you what they'd pay for
- When you have reviews and case studies
- Gate advanced features, not core functionality
- Offer email/phone support as a paid differentiator
The key insight: your feature toggle system is your monetization engine. If you build with Custom Metadata Type toggles from day one, separating free and paid tiers later is just a configuration change. No code rewrite needed.
The Honest Part
Things That Surprised Us
Every AppExchange journey has moments where you think "nobody mentioned this." Here are ours.
Surprise #1: Things Break When You Add a Namespace
Your code works perfectly in your dev org. Then you add a namespace prefix and suddenly certain references stop resolving. Not everything. Just enough to ruin your afternoon.
Static SOQL, Apex class references, @salesforce/apex imports in LWC, custom label references, Flow references within the package. The compiler and platform handle these automatically.
Hardcoded objectApiName strings in LWC JavaScript (NavigationMixin calls), permission set names used in string comparisons in SOQL, and any dynamic references that rely on the un-prefixed API name.
Surprise #2: Your Test Framework Might Have Bugs
We ran our test suite through a regression testing tool. The results looked terrible: 18.9% pass rate across 74 tests.
After investigating every failure, we found something unexpected: none of the failures were caused by our code. They were all bugs in the testing tool itself.
The best one? An assertion type called "No Error" that was supposed to execute our code and verify it ran without errors. It never executed the code at all. It just searched for a test class matching our code string, found nothing, and reported "passed" because "no failures found." Ten of our tests passed by accident.
A passing test only means something if the test actually ran your code. We had 111 real unit tests as our safety net, and that's what actually mattered.
Surprise #3: The ISV Portal Is... Not Intuitive
The Salesforce Partner Community portal where you manage your listing is functional but not exactly user-friendly. Finding the right page, understanding what to fill in where, and figuring out the correct order of operations took more time than we expected.
There's no guided wizard that walks you through the process. You're navigating between different sections, and the relationship between your Dev Hub, your packaging org, your namespace, and your listing isn't always obvious.
Surprise #4: Screenshots Matter More Than You Think
We initially treated screenshots as an afterthought. Just grab a few screens and upload them. But screenshots are the first thing potential users see on your listing page. They're your storefront window.
Spend time on these. Use real data (not empty screens). Annotate key features. Show the product doing something valuable, not just sitting there.
What We'd Tell You
Advice for First-Time AppExchange Publishers
with sharing. Every DML gets a CRUD check first. Use bind variables in all SOQL. Do this from the first line of code, not as a retrofit. And test security patterns in a namespaced org early — some standard approaches behave differently in 2GP packages.
The finish line exists. The track is longer than you think.
Looking BackWas It Worth It?
Yes. Without question.
The process is longer and more complex than we expected. The waiting is frustrating. The documentation could be better. The partner portal could be more intuitive.
But we went from having an internal tool that helped one team to having a product that's available to every Salesforce org in the world. That's a fundamentally different thing.
If you have an app that solves a real problem, and you're willing to invest 8-12 weeks in the publishing process, AppExchange is worth it. Just go in with realistic expectations about the timeline, start the paperwork early, and don't be surprised when the security review takes longer than you hoped.
"Building the product was the fun part. Publishing it was the education. Both were worth doing."
Going Through This Yourself?
If you're building your first AppExchange product and want to compare notes, or if you've been through this process and have tips to share, we'd genuinely like to hear from you.
forceraft.com | Find us on the Trailblazer Community