Do you already have your SaaS product, but would like to integrate it into Salesforce and release it on AppExchange?
Or you are a Salesforce Developer/Consultant with a brilliant idea for a Salesforce app?

If you don’t know where to start this journey, feel lost in Salesforce technical jargon ("first- vs second- generation packages, LMA, LMO, DevHub, COA" – sounds familiar? ;)) or start getting tired untangling the whole process ingredients, we have something for you.
Here’s the AppExchange App Publication Checklist with a brief overview of each step.

AppExchange App Publication Checklist

1. Sign Up for the Salesforce ISV Partnership program and become a Salesforce Partner.
2. Identify different types of Salesforce orgs involved in the app creation process.
3. Learn how to create Support Cases via the Partner Portal.
4. Choose Between 1st and 2nd generation packaging.
5. Develop Salesforce Managed Package.
6. Configure listing on the Partner portal and get approved.
7. Get your Partner Business Org activated.
8. Pass Salesforce Security Review.
9. Configure payments.
10. Register the package and select the default license configuration.
11. [Optional] Configure trial versions of your app.
12. Configure lead collection.
13. Test the full process on different types of orgs.
14. Publish Your App!
15. Manage Customer Licenses from your Partner Business Org.
16. Analyze how customers find your app with Marketplace Analytics.
17. Understand how customers use your app with AppExchange App Analytics and custom solutions.

Sign Up for the Salesforce ISV Partnership program and become a Salesforce Partner

The first step you need to take is going to https://partners.salesforce.com and completing the Sign Up process.

Click the Become a Salesforce Partner button to start the signup process.
After you finish that, you’ll need to wait for Salesforce to verify your request. It typically takes a few days.
When they’re ready, you will receive a welcome email from your dedicated Partner Account Manager (PAM) – this will be your key point of contact at Salesforce.
Apart from that, you will receive Salesforce org credentials – this will be your Partner Business Org – the most important org for your Salesforce partnership – your own Salesforce production org.
Speaking of Salesforce orgs, let’s move to the next section.

Identify different types of Salesforce orgs involved in the app creation process

If you were reading Salesforce ISV documentation, you might have encountered many different Salesforce orgs names.
Here’s an overview of the orgs you will most probably interact with while publishing the app:

1. Partner Business Org (PBO) – your own Salesforce Production (with a limited number of licenses) that you receive for free after signing up for the partnership program. It’s provisioned in trial status and expires after one year. You will be able to transition to active state after your app listing gets approved. This will be a master org for all activities related to your app, partnership, customer management, etc. You will also use this org’s credentials to log in to the Salesforce Partner Portal.

2. License Management Org (LMO) – it’s the same as your PBO (unless you explicitly request otherwise) – the name indicates that a License Management App is installed on this org. This app allows you to manage customer licenses for your app.

3. Devhub – if you’re using 2nd generation packaging (which you probably should!), this will again be your Partner Business Org (but you need to enable Devhub setting yourself). Devhub is a master org for 2nd generation managed packages. Every package is associated with one Devhub org. Additionally, it is a source for creating scratch orgs – short-lifespan orgs used for development.

4. Namespace Org – each Salesforce package is associated with a namespace. This is a short sequence of characters (usually an abbreviation of your app/company name) that gets prefixed before every component name included in the package. This is to prevent conflicts when your customer already has some components with the same names as the ones included in your package.
   The namespace org is a place where you register such a namespace. Then you link your namespace org to the Devhub Org.

5. Scratch Org – short-lifespan (max 30-days) org dedicated for development purposes. You’ll probably use such orgs to develop your app.

6. Developer Edition Org – another org type that you can use for development. This doesn’t expire after 30 days, but it’s much less configurable (e.g. you can have scratch orgs imitating different Salesforce Editions and Developer Edition is only one of them).

7. Packaging Org – relevant only if you’re using 1st generation packaging (which you probably shouldn’t!). It’s a master org for 1st generation packages – you create them from there.

Learn how to create Support Cases via Partner Portal

It’s not a coincidence that this is a separate point here. You will probably encounter some issues during the app creation/publication or you might simply have some questions for Salesforce Support.
To create a new Support Case:

1. Log in to the Salesforce Partner Portal (most probably you need to use your PBO credentials).
2. Click the question mark sign at the top right.
3. Select Log a Case for Help

Choose Between 1st and 2nd generation packaging

You might have seen the 1st generation packaging and 2nd generation packaging mentions everywhere in Salesforce articles or forums. Those are just two different technologies to create Salesforce packages (each AppEchange app is a Salesforce managed package).
Long story short, you should always choose 2nd generation packaging unless some component you want to use is still supported only by the 1st gen. packaging. This happens super rarely 😉 To check whether the components you want to include in the package are supported by 2nd gen. packaging, reference the Salesforce Metadata Coverage Report.

Develop Salesforce Managed Package

As I already mentioned, Salesforce AppExchange app is simply a Salesforce managed package published on the AppExchange. Obviously, you need to develop it to have something to publish. You can do it yourself or hire a good Salesforce Developer (the best ones write on this blog ;)) or Salesforce Partner Company (did someone say "Beyond The Cloud"?).

Configure listing on the Partner portal and get approved

The AppExchange listing is a dedicated site for your app on AppExchange (here’s an example).
You configure it from the level of the Salesforce Partner Community.

1. Log in to the Salesforce Partner Portal.
2. Go to Publishing -> Listings.
3. Select New Listing.

The configuration wizard will guide you through the app details population.

One of the steps is getting approval from Salesforce after you decide on your pricing model. You submit the listing for approval from the level of the configuration wizard.
Now Salesforce will check if your app complies with their policies. You will receive the confirmation email once the listing gets approved.
If you’re releasing a paid app, they will also send you the Revenue Sharing Agreement (as a partner you share the income from your app with Salesforce) to sign.
If your app is free, you’ll probably receive an email asking you to confirm that the app complies with Salesforce’s definition of "free".

Get your Partner Business Org activated

After you get your app listing approved, you can ask Salesforce to transition your PBO from Trial to Active status. Raise a Support Case for that.

Pass Salesforce Security Review

Every AppExchange app must pass a security review conducted by Salesforce. Salesforce wants to make sure that no insecure apps are distributed there.
At the moment of writing this post (November 2024), this pleasure costs you 999$ per attempt if you’re publishing a paid app, and 1$ per attempt if you’re publishing a free app.

Preparing your app for the security review is a huge topic and requires a lot of work. I’m leaving a link for the official documentation on this here, but also recommend you hire Salesforce professional with AppExchange expertise to help you in the process. Especially if your app integrates with external systems.

All the materials you produce during the preparation and the security review submission management itself are managed through the Salesforce Partner Portal (Publishing -> Technologies -> Your Package -> Start Review).

Configure payments

You could have done it as part of the listing configuration, but this is the right moment to make sure everything is in place.
You have two options to manage your payments:

1. AppExchange Checkout – Salesforce’s native solution that will manage payments on your behalf and automatically take Salesforce’s revenue part from you (more details about this can be found in this article). You will need to create a Stripe account (from the level of the listing) and it will get connected to AppExchange Checkout.
2. Manage payments yourself – you are free on how you collect the payments, but you will need to report your earnings to Salesforce so that they can charge you for their revenue share part. They have a dedicated app used to report revenue – Channel Order App – you can learn about it in the official Salesforce documentation.

If you’re wondering which option you should choose, I’d say always go for Checkout if you can – you won’t be troubled with revenue reporting. But it is unfortunately very limited and if you want to have a complex pricing model (e.g. freemium, multiple plan tiers, pay for the number of requests), you will need to manage the payments on your own.

The pricing is configured from the level of your app listing on the Partner Portal (Publishing tab).

Register the package and select the default license configuration

As a next step, you should register the package in the License Management App (which, as I already mentioned here, resides on your PBO if you didn’t request otherwise). This is to ensure every time somebody installs your app, you will see a new license record on your org (LMO). More info about license management is included in the Manage Customer Licenses section.

You can complete the aforementioned registration from the level of the Salesforce Partner Portal.

1. Log in to the Salesforce Partner Portal.

2. Go to Publishing -> Technologies and click Register Package near the package version that passed the security review. _Note: to see the correct packages here, you must have linked the correct package to your listing during the listing configuration.

3. Provide your LMO (which is probably also your PBO) user credentials to set up the under-the-hood integration.

   

4. Select the default license configuration to decide what license will be available to the customer by default when he installs the app. If you manage your payments via Checkout, it will force the customer to purchase the appropriate license no matter what you select here.

   

[Optional] Configure trial versions of your app.

There are a few ways to enable your customers to try out your package before payment:

1. Trial license duration configured via Checkout (obviously, available only if you use checkout to manage payments) – it will let your customers use your app for a specific period of time before requesting the payment from them.
2. Trial license duration configured during the default licenses configuration – the license will simply expire after some period of time unless you enable the full license for the customer earlier.
3. Test Drive – your package is installed on a read-only org that your customers can access anytime.
4. Trialforce – separate Salesforce org that your customer can use in a non-read-only mode, make his customizations there, and even convert to a production org later.

More details about Test Drive and Trialforce can be found here.

Configure lead collection

You can configure the app listing to automatically create lead records on your License Management Org when potential customers interact with your listing – e.g. when somebody watched your demo, used the test drive or installed the app.

Test the full process on different types of orgs

You should definitely test the full process from the perspective of your customer. You can create your own test org via Environment Hub, login to AppExchange, and install the app there.
That way you’ll be sure not only that the package works as expected, but also that you configured correctly everything that is described in this article.

Publish Your App!

Well done my Friend, you did it! It took some effort, but I hope it was worth it (yeah, you don’t know it yet, but I keep my fingers crossed for your app’s success!).

But please, don’t stop yet, I have a few pieces of advice more 😉

Manage Customer Licenses from your Partner Business Org

As I already mentioned, after you register your app in the LMA, anytime a customer installs your package, a new license record will be created on your LMO org.
This record controls your customer’s access to the app after installation. By modifying the license record, you can decide how many users in the customer’s org can use the app, the expiration date, and the app plan version. You can even suspend the app for customers who are not paying their invoices on time.

More details on the license management topic can be found in the official documentation.

Analyze how customers find your app with Marketplace Analytics.

You can monitor how the customers find your app and see related metrics via Marketplace Analytics. The information visualized there contain:

• listing landing source (e.g. 50% of the customers find your app via Google and 25 through AppExchange search)
• most relevant searches that led to your app
• number of listing visitors across time
• country distribution of the customers interacting with your listing
• engagement scores for different parts of your listing
• … and more

You can access those data by logging into your Salesforce Partner Portal account (Publishing -> Analytics).

You can learn more about Salesforce Marketplace Analytics here.

Understand how customers use your app with AppExchange App Analytics and custom solutions.

Marketplace Analytics gives you information on how your customers find your app. But what about knowing how they actually use the package, which features they interact with, and how often?
Salesforce collects such data in App Analytics Logs that you can manually request for a certain period. Then you’re able to import those logs into your favorite visualization tool and draw some useful conclusions.
You can learn more about AppExchange App Analytics here.

Requesting the App Analytics logs manually, importing them to Excel, and creating visualizations on your own every time you need to have a look at the fresh analytics data can be very troublesome.
We were also facing this issue with our apps and that’s why we created a dedicated app that can do all of this for you. It takes a few minutes to configure and gives you crucial information about your app, such as:

• Which features are being actively used by your customers?
• How many users are interacting with your app and how often.
• Where do those users come from? Map with countries.
• Is your app usage increasing or decreasing over time? Were some quarters or months particularly successful?
• Did any unhandled errors occur for the customers? For which? Where is the bug?
• Which customer licenses are about to expire soon?
• Which customers require your attention (because they are not utilizing all the licenses or have low usage)?

This can help you make better product roadmap decisions, prevent churn, monitor the customers’ health, and make sure your product is of top quality.

You can install this app on your Partner Business Org and see all the data from there. Be sure to check it out: ISV Analytics – AppExchange App Analytics.
BTW. This is an AppExchange app and we followed the steps described in this article. You’re in good hands 😉

OK, enough of this intrusive advertising! Let’s recap what we’ve learned.

Conclusion

After the first attempts to go through the official docs, publishing the AppExchange application may look like a super-complicated challenge. In fact, this is a structured process that has specific steps to follow. Whenever you feel lost in this journey, remember about a great post on the Beyond The Cloud blog that you’ve just read, come back to it, and start checking the boxes on the checklist.

We can help you (another shameless promotion)

If you don’t want to go through all of this on your own or need help in some of the steps, be sure to reach out to us. You can write an email to contact@beyondthecloud.dev, message us on LinkedIn (https://linkedin.com/company/beyondtheclouddev), or send a direct message to me (https://linkedin.com/in/bartosz-suchocki).
Whatever you choose, expect a quick response and great cooperation!