How to publish your App on AppExchange
I had the pleasure to speak on this year's CzechDreamin. And as I promised to some of you, I will try to summarize the topic that I presented there. I will be more specific and bring you more information. To be honest, I wasn't very precise in choosing the time slot. 25 minutes for this topic wasn't enough.
So how to publish your application to AppExchange? I will now share with you my recommendation and best practices.
So let's get into it.
What the hell is AppExchange?
Let's imagine that you bought a new apartment. You are very satisfied and happy with it. Apartment is nice, big and gives you a lot of options. There is a certain parallel to Salesforce. However, it is not complete, you will also need some furniture such as a bed, chairs, a table, or a sofa. Basically, you want the apartment to meet all your requirements. That's why you need to head to the store. In our case, we're visiting the AppExchange. Here, we have the opportunity to find possibly thousands of applications that we can install into our Salesforce and thus expand its capabilities.
That's how the functioning of the AppExchange can be summarized. Of course, applications are paid or free (or there are trial versions). As you would expect, it works very similarly to the App Store or Google Play. You need to be registered, logged in, and then you can install the application.
Publication process – Overview
Occasionally tiring
Demanding in terms of preparing necessary materials/inputs
Interesting
Complex
Simply put, the process is lengthy. You must prepare a lot of materials that cover information about the company, the application, the plan, marketing, and vision.
We can split it into two main categories:
Business review
Security review
It is paid… but let's check that a little bit later.
Partnership
Yes, this is the first necessary prerequisite for a person to even begin the actual process. You need to be a Salesforce Partner. There are many levels of partnership, and the official documentation will surely provide more information if you're interested in that. You can find it here or here.
The minimum level of a partnership is ISV - Independent Software Vendor. This could mean that you are an implementation partner, providing your services to customers and advancing their system. Alternatively, it could simply mean that you want to publish an application. Yes, without that, we won't make any progress.
The path to becoming a partner is straightforward. First, you need to register on the Partner Communities. After registration and providing all the necessary information, you need to be approved. Surprisingly, there is an approval process even here.
After successful approval, we can proceed because we have access to a feature in the communities called the "Publisher Console."
The Publisher Console is a tool where you manage the entire publishing process. Here, you fill in information about your company and application. It also covers how the solution will be licensed, allows you to see generated leads, and more.
Application Development
Before you start, make sure you do a thorough quality research. Without it, it doesn't make sense to start with the process, as recycled applications are not the right path to take.
Partner Developer Org
The first org you need to have is the Partner Developer Org or a standard Developer org. In this type of org, application development takes place. The PDO can be created from the Environment Hub, to which you have access as a partner. The advantage of a partner org is that it has higher limits, including API limits, data storage, and so on.
Partner Business Org
The next one in line is the Partner Business Org (PBO). Simply put, this is where you manage license work using the License Management App (LMA) and orders through the Channel Order App (COA). It is an environment that you, as a partner, must have.
Test org
Without a doubt, you need an environment where you can test your app! You can use your standard org, create one from the hub, or work with a developer org for that purpose.
Of course, it is essential that all instances are linked to the partner profile. Part of this process is providing information about your company. Salesforce wants to collaborate with a verified and stable company.
Certainly, you can publish various types of applications. Which means you can publish an application based on Salesforce, on Marketing Cloud (though I'm not familiar with the specifics of how it works for MC), or even an application that doesn't have Salesforce components. For example, you may have a ready-to-use tool that solely utilizes Salesforce API to retrieve and store data locally or on a server. Yes, it's a data backup application. However, I must say that such a publication was indeed challenging (3-4 months, phew!).
When working on an application, it is crucial to follow Salesforce Best Practices and standards. This is a very important aspect that will be evaluated during further reviews, especially in terms of security. As expected, code coverage is also essential.
As I mentioned before, without thorough research, it doesn't make sense to proceed. Therefore, your solution should bring some interesting feature that the system doesn't have or potentially extends its capabilities. A great example is the "Mass Delete" solution. The application is directly from Salesforce Labs and provides a much-needed enhancement to the standard Salesforce functionality.
Another exciting part after completing development is preparing the package, which contains components of your solution. There are two types of packages:
Managed package: In this type of package, the components are managed by Salesforce, and there are certain restrictions on modifications. Once installed, it is not possible to make extensive changes to these components. However, some partial modifications, such as removing a field, may be allowed.
Unmanaged package: On the contrary, an unmanaged package allows greater flexibility in modifying its components. You can make changes to the components even after installation, such as adding or removing fields or making customizations as needed.
I hope this documentation helps clarify the differences between the two types of packages.
The result of packaging the components is a package, which has a name, installation link, specific version, and of course, a description. It is also possible to work with versions and create beta versions.
The actual process of preparing a package is straightforward and is very similar to working with Change Sets. You simply select all the items you need (flows, layouts, fields, tabs, etc.) and package them together.
Business review
And here comes the bureaucratic part, but it's certainly not the worst part.
During this phase, your task is to provide Salesforce with valid information about your company, product, plan, certifications (not referring to whether you are a certified Pardot specialist or similar), marketing materials, and selection of your pricing as well.
Business Details
You need to provide information about your company (as mentioned above), the market your product is targeting or should be primarily focused on, and finally, information about key users. This helps Salesforce better understand how your company fits into the Salesforce ecosystem.
Product Architecture
Sharing information about your product includes how it is built, how credentials are managed, and how you handle sensitive data, for example. This helps Salesforce assess whether you are following their best practices and adhering to standards, both in terms of design and architecture.
Compliance Certification
Corporate business practices. I wasn't aware that such a thing exists, but as a matter of fact, it does. For Salesforce, it is important to know if you align with their standards for ethics and integrity.
As mentioned, you need to provide a substantial amount of information and documents. However, it doesn't make sense to describe everything in detail, so let's move on to pricing.
Licensing
In the previous section, we discussed how AppExchange works and touched the subject of pricing. Now is the time to dig a bit deeper into this topic.
There are several types of licenses:
Licenses per Company
Licenses per User
Free Licenses
Trial Licenses
Monthly Licenses
Annual Licenses
The specific licensing model you choose will depend on your application, target market, and business strategy. It's important to carefully consider your pricing and licensing options to ensure they align with your business goals and customer expectations.
Sure. Of course. How else? Salesforce takes a percentage from your sales volume. How much? Officially, I don't know, but unofficially it's reportedly around 15% for ISVs (Independent Software Vendors).
And now it's time to prepare for the call with Salesforce representative from AppExchange. During the call, you will go through company information and, most importantly, do a demo.
Security review
And here I am. The security review is a nightmare for many people, and I can't blame them! When I worked on my first publication, this process was a complete black box to me. Literally.
This review is entirely in the hands of Salesforce, and it's up to them whether they approve it or not. Simply put, they examine your solution from a technical perspective, from A to Z. This means they check all the components included in your solution (package). It makes sense, though. They want to ensure that the app you want to install in their system is secure, high-quality, and fully functional.
How can you prepare for it? Here are a few recommendations:
UI - Implementation - Testing
You need to prepare your solution as if you were preparing a project, aiming for the highest possible quality. Consider asking yourself the following questions:
Is the design user-friendly and intuitive?
Is everything functioning smoothly without any issues?
Is the solution scalable?
Definitely prepare documentation, both technical and user-oriented. Comprehensive documentation can assist the technical team in understanding how the application works and potentially address any questions that may arise.
The final step is testing. Test, test, test. In my opinion, this is one of the most crucial aspects. Provide your solution to colleagues, friends, and family, and gather feedback. This will help you uncover any issues or areas for improvement that may have been overlooked during development.
Testing should cover various scenarios, including positive and negative test cases, edge cases, and performance testing. Automated testing can also be beneficial to ensure consistent and reliable results. Additionally, consider usability testing to gather feedback on the user experience and identify any areas that need refinement.
By investing time and effort into thorough testing, you can increase the overall quality and reliability of your solution, leading to better user satisfaction and adoption.
Best practices
Take a look at the recommendations for the Security review.
Static analysis. Salesforce requires a report from tools such as ZAP and Checkmarx (Checkmarx is recommended by SF). You will receive a report of your application as the output.
Comment report - create a False Positive document. You need to comment on and explain each item in the report (if I'm not mistaken, from a medium-level rating and above).
Again and again! Best practice. Beautiful words. Stick to them – and build your application on them.
Prepare your org for the review. Remove invalid components, provide access to the SF team, or set IP ranges.
Yes, you are right. This whole section is incredibly broad, and the official documentation from Salesforce provides detailed information and guidelines. I recommend referring to their official documentation as it will offer you more comprehensive insights. As I mentioned before, my article provides a basic description and primarily focuses on recommendations.
The finish line is coming! Now, let's check the pricing for this…
Maybe you know the old model, yes old! Pricing model was changed this year (March/April 2023). Previously you had to pay for:
Security review - 2550 USD – one time
App Listing - 150 USD – every year
This means that if the security review was unsuccessful, the subsequent reviews were free of charge, and this continued indefinitely. The App Listing fee was paid annually, which meant paying $150 for having the application listed. This pricing structure applied to paid solutions. For free apps, the review was free, and only the listing fee was applicable.
Whooom! Change!
Salesforce is very strict about its payment model for certain things, and therefore I only have unofficial information available.
According to the new model, both fees have been cancelled/changed. The listing fee has been eliminated, and only the fee for the Security review remains. However, there has been a change in that fee as well. It is now $999 per attempt! So, if the review is unsuccessful, the fee needs to be paid again for each subsequent attempt. Based on the information I found, it typically takes 2 to 3 attempts to successfully publish an application.
The question is, how will it be for solutions that are already listed and the owner comes up with an update, for example? It appears that the first re-review will be free. But what about subsequent ones? Surprise, they are paid.
It is unclear whether this model applies to free solutions as well. There was no mention of it, so I assume it does. It seems that even for a solution you want to provide for free, you will have to pay (this is only my presumption).
UPDATE: Based on new information from some of you – you must pay for Listing too. Same price 150 USD
It is not a cheap fun…
BUT this surely won't happen to you, you will succeed on the first attempt, and then it's just a matter of pressing the "Publish Listing" button.
I wish you the best of luck with this process, and please do share how it turns out and if this article was helpful. If you have any questions or updates, feel free to send me an email or DM on LinkedIn.