Package Publication
Package Publication in Salesforce is the multi-step process of taking a managed package from internal development to the AppExchange marketplace where customers and prospects can discover, evaluate, install, and use it.
Definition
Package Publication in Salesforce is the multi-step process of taking a managed package from internal development to the AppExchange marketplace where customers and prospects can discover, evaluate, install, and use it. The process spans technical preparation (building a release-quality package version, ensuring test coverage, documenting features), business preparation (pricing, licensing, marketing collateral, demo environments), and the Salesforce-mandated Security Review where the package code and architecture are independently assessed for security vulnerabilities before commercial release.
Publishing a package to AppExchange is the canonical path for Independent Software Vendors (ISVs) building on Salesforce, but it is also relevant for Salesforce Labs apps, system integrator consulting offerings, and enterprise customers distributing internal apps to subsidiaries. The publication process is rigorous because AppExchange has a strong reputation for quality and security, and Salesforce protects that reputation through the Security Review and listing standards. ISVs that complete the publication process gain access to a massive Salesforce customer base; those that cannot meet the standards do not publish, which is part of how the marketplace maintains quality.
The Package Publication lifecycle
Development and packaging
Before publication, the ISV builds the package in a development org (often a free Partner Developer Edition org provided by Salesforce). The package contents are organized into a managed package, with a registered namespace prefix that scopes the components. The package version is built and tested in the development org, then in beta-test orgs that simulate customer environments. The packaging itself is straightforward via Salesforce DX (sf package version create) or the older first-generation packaging tools. The package version becomes the artifact that goes through subsequent review and publication.
Security Review
The Security Review is the mandatory Salesforce-led assessment of the package's security posture. The review evaluates: SOQL and Apex injection vulnerabilities, sharing model integrity, sensitive-data handling, OAuth scope appropriateness, third-party library usage, cross-site scripting risks in Visualforce or LWC, and proper use of platform security features. The review takes weeks to months depending on the package complexity and any required remediation. ISVs typically engage with the Salesforce Partner Security team early in development to understand the requirements, so the final review is faster. Passing the Security Review is the gating criterion for AppExchange listing; without it, the package cannot be published.
AppExchange listing creation
After Security Review approval, the ISV builds the AppExchange listing: product name, marketing description, pricing model (free, paid, freemium), demo videos, screenshots, customer testimonials, support documentation, install instructions. The listing is built through the Partner Community portal. Salesforce reviews the listing for completeness, brand consistency, and content quality. The marketing investment in the listing materially affects discovery and conversion: high-quality listings with rich content outperform sparse listings significantly. ISVs that treat AppExchange listings as an afterthought see correspondingly low pipeline from the channel.
Trialforce and demo environments
For paid packages, ISVs typically provide a trial experience: a way for prospects to test the package without commitment. Trialforce is the Salesforce-provided infrastructure for hosting trial orgs: prospects sign up, an org with the package preinstalled is provisioned, the prospect uses the package for a trial period. The trial conversion rate is a key business metric for ISVs. Building a compelling trial experience (preloaded sample data, clear getting-started flow, easy upgrade path to paid) significantly improves conversion. ISVs without trial infrastructure typically convert at much lower rates than ISVs with well-designed trials.
License management
Paid packages need license management infrastructure. The Salesforce License Management App (LMA), installed in the ISV's own org, tracks customer installations: which orgs have installed the package, how many seats they have, when their licenses expire. The LMA integrates with the ISV's billing system to handle license provisioning, renewals, and revocations. Salesforce provides standard LMA functionality; ISVs with complex licensing models often build custom extensions. Getting license management right matters because every customer relationship depends on the ISV being able to deliver and manage entitlements correctly.
Customer support and the Partner Community
Published packages need customer support. ISVs commit to support response times, version compatibility, and security patch policies as part of the AppExchange listing. The Salesforce Partner Community provides the connection point: customers report issues through the Partner Community, ISVs respond, and Salesforce supports both sides with the relationship infrastructure. Mature ISVs invest in support tooling (Knowledge bases, support portals, premium support tiers) alongside the package itself. The support quality affects customer retention and AppExchange reviews, both of which drive future sales.
Updates, new versions, and customer upgrades
After initial publication, ISVs continue to release new package versions with bug fixes, new features, and platform compatibility updates. Each new version goes through a lighter version of the Security Review if it introduces changes that affect security posture. Customers receive notifications about new versions and choose when to upgrade (Salesforce does not auto-upgrade installed packages without customer action). Communicating new features clearly, managing the upgrade path carefully, and maintaining backward compatibility are ongoing publication-related disciplines that distinguish successful ISVs from struggling ones.
AppExchange business model and revenue share
Beyond the technical publication process, AppExchange has a commercial model that ISVs must understand. Free and Salesforce Labs apps carry no fee. Paid apps share revenue with Salesforce through the Partner Program: the standard arrangement is 15 percent revenue share for ISV-priced apps, with various deals for higher-volume or strategic partnerships. Annual partner fees and tier requirements (Premier, Crest, Ridge, Summit) shape what marketing benefits and Salesforce-led pipeline access ISVs receive. The Partner Program also has technical requirements: maintaining the package through Salesforce major releases, responding to customer support tickets within agreed SLAs, completing periodic security re-reviews on a defined cadence. ISVs that meet all these requirements operate sustainably on AppExchange; ISVs that struggle with the requirements often delist or fall behind on customer engagement. The decision to publish on AppExchange is therefore a multi-year commercial commitment, not just a one-time technical event. Successful ISVs treat the AppExchange business as a strategic line of business with dedicated product management, engineering, marketing, and support resources rather than as a side project of consulting work. The commercial discipline required is substantial, and the Salesforce Partner team provides significant guidance to ISVs willing to engage with the program seriously.
Common publication pitfalls
Three pitfalls recur in Package Publication efforts. Underestimating Security Review: the review is more rigorous than most first-time ISVs expect, and remediation cycles often add months to the launch timeline. The fix is to engage with the Partner Security team during development rather than waiting until the review submission. Sparse marketing content: ISVs that focus on the technical product and treat the AppExchange listing as an afterthought see correspondingly low conversion. The fix is to invest in the listing as if it were a product launch in its own right. Poor trial experience: prospects given a Trialforce trial that does not clearly show value abandon quickly, and the lost trial is rarely recovered. The fix is to invest in the trial as a designed customer journey rather than just a preinstalled package. Each pitfall is preventable but recurs predictably across ISVs that have not learned them from prior launches. The Partner Community is the best resource for learning these lessons before encountering them: other ISVs who have already published share what worked and what did not.
Publish a Salesforce package to AppExchange
Publishing a managed package to AppExchange is a months-long project, not a single task. The walkthrough below covers the standard sequence from initial planning through commercial availability, with the understanding that each step has its own substantial subprocess.
- Engage with the Salesforce Partner team
Apply for the Salesforce Partner Program if not already enrolled. Engage with a Partner Account Manager who can guide the publication process. Get a Partner Developer Edition org for development, register the namespace prefix, and start building the package. Attend the Partner-specific training resources on Trailhead and the Partner Community. The early relationship with the Partner team makes the rest of the process significantly smoother.
- Build, test, and prepare for Security Review
Develop the package to production quality: complete features, polished UX, comprehensive Apex test coverage (75 percent platform requirement, but 90 percent or higher recommended for review), full documentation. Run the Checkmarx or Chimera security scanning tools against the package and remediate findings. Submit the package for Security Review through the Partner Community. The review takes weeks to months; budget for multiple rounds of remediation feedback before approval.
- Build the AppExchange listing and trial
Create the AppExchange listing with marketing content, screenshots, demo videos, pricing, and customer testimonials. Build the Trialforce trial template that prospects will experience. Configure the License Management App for entitlement tracking. Test the entire customer journey end to end: discovery, trial signup, trial usage, purchase, install, license activation. Iterate until the experience matches what your sales team is comfortable selling.
- Launch, market, and iterate
After Salesforce approves the listing, launch the package on AppExchange. Promote through your standard marketing channels: customer outreach, partner channels, content marketing, AppExchange-specific events like Dreamforce. Monitor adoption through LMA: which orgs install, what their usage patterns look like, what feedback they provide. Iterate on the product based on early customer feedback. Release new versions on a regular cadence to maintain momentum and address customer requests.
- Security Review can require multiple rounds of remediation. Budget months, not weeks, for review completion.
- Namespace prefixes are permanent. Choose carefully because changing requires rebuilding the package entirely.
- Trialforce trial conversion rates depend heavily on the trial experience. Sparse trials produce sparse conversions.
- LMA configuration affects every customer's licensing. Misconfiguration leads to billing disputes and support burden.
- AppExchange reviews are public and influence future sales. Customer support quality directly affects long-term pipeline.
Trust & references
Straight from the source - Salesforce's reference material on Package Publication.
- Packaging GuideSalesforce Developer Docs
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 Package Publication?
Q2. What does publication include?
Q3. How long can security review take?
Discussion
Loading discussion…