Public or Private Listing: How to Determine Your App’s Distribution on AppExchange

Launching an app in the fastest-growing cloud economy is an exciting thing for any partner. AppExchange is home to 4,000+ solutions to help extend Salesforce into any department or industry.

But when it comes to the distribution strategy of your app, perhaps you need a little extra guidance. In this example, we’re going to walk through a scenario where a partner has a very popular app built for Classic. The partner wants to upgrade the Classic app to Salesforce Lightning, but they have some questions before they proceed. In this blog, we’ll go through the decision-making process, ponder over different options, and determine the best strategy.

Terminology 101

Let’s cover some of the terminologies I’ll be using in this example.

Package: Code components such as classes, pages, and flows packaged as a bundle for easy deployment. A packaging org where the package is built has a namespace for security. You cannot access code from one namespace package to another unless the classes are defined as Global.

Listing: An entry on the AppExchange marketplace that customers can both search for and install the package by clicking on the URL. Listings are designed to be SEO-compliant for easier search, can be rated by the customers, and are a great marketing presence along with other features. It is a 1:1 relationship, meaning one listing points to one package, although the package can be switched. For example, if we have a ListingA tied to PackageA, it is possible for ListingA to point to another package, PackageB.

Public Listing: These are the entries that are searchable on AppExchange.

Private Listing: These are the entries that are not searchable. A partner can choose to distribute the solution via private listing URL to select customers.

Private vs. Public: A Scenario

Let’s walk through an example. An AppExchange partner inherits a Classic app, developed by a third-party vendor, which will be deprecated in a few years time. The new app is very different architecturally, developed by an entirely different vendor, and is going to be on Lightning. This brings about questions to ponder:

• Does it make sense to have a single listing with both Classic and Lightning components in a single package?
• How does search work on the AppExchange marketplace for the listings?
• If there are two listings, will the partner need to start from scratch and rebuild the search presence such as number of views, listing score, rank etc.?
• What about maintenance, bug fixes, — and what should happen if a customer wanted to upgrade from Classic to Lightning?

When faced with these questions, there are generally three options to consider.

Option 1: Keep the current public listing and associate with a package containing both Classic and Lightning Components.

Option 2: Keep the current public listing and associate with the new Lightning package; Create a private listing pointing to the Classic package

Option 3: Keep the current public listing associated with the Classic package; Create a new public Listing associate with the Lightning package

Using a decision matrix, we can list the pros and cons associated with each option to make comparisons and draw conclusions.

Using a matrix like the one displayed here, you can see there are many considerations when it comes to upgrades and distribution. In this example, the partner decided to go with Option 2 for simplicity and easier maintenance. Others might arrive at a different decision — it’s all about what’s right for your processes.

Conclusion

The distribution of an app on AppExchange requires careful deliberation. It is important to build a decision matrix that helps us arrive at the best possible outcomes — and also knowing that decisions are reversible to a certain extent. We recommend working with Salesforce’s ISV team to arrive at the optimal decision.