ScoreHub, Part 10. AppExchange release

It has finally happened - ScoreHub was released on the AppExchange!

This was an amazing milestone for the project and me personally. It took a lot of time and effort to get to the point where I was finally ready to hit the "Submit" button, and it was as much of a learning experience for me as developing the application itself. It wasn't flawless though, and I want to share my journey and point out some of the things that might simplify your experience when it comes to releasing apps on the AppExchange.

Using Developer Edition versus Partner Business Org

If you were following this blog you probably knew already that I was using Salesforce Developer edition Org as a DevHub for ScoreHub. This was due to the fact that it was easy to set up and use for building a POC. This worked just fine, but once I started investigating what I would need to do to release an app, I realized that this approach didn't align with the vision outlined in the Salesforce ISV Partner Journey. Not only was I missing some benefits, but the fact that I was using the Developer Edition org instead of Partner Business Org might mean a rejection from the Security Review team.

Basically, the journey from nothing to releasing an app outlined by Salesforce looks somewhat like this:

But instead, my journey looked like this:

Have I told you that this was a learning experience for me? ??

The problem was that even though I was able to utilize Developer Edition org to create a functional package and pass security checks by Checkmarx and PMD tools, manual security review requires you as a partner to have an active PBO, but also to have your package built by DevHub which is configured on your PBO. The last part is just a recommendation since you technically can connect multiple DevHubs to a single Partner account, but trust me - you don't want to avoid recommendations when it comes to a security review process. And since I was trying to do it all by the book, I had to switch my DevHub, and re-configure CI/CD to use it. The good news was that it was a great test to check how robust my CI/CD was and since I was able to reconfigure everything in 10-15 minutes I think I've passed that test.

In the end, my recommendation is this - try to switch from Developer Edition Org to Partner Business Org as soon as you have a modicum of confidence that you will eventually release your project on the AppExchange. I would say, a general rule of thumb would be right after you have a working POC and you are ready to spend time finishing it up to have an MVP. And, while "becoming a partner" sounds scary it is fairly simple - you just need to register in the SF Partner Community and create a listing for your project. After that, you will be contacted by the partner manager from Salesforce and if everything is okay your PBO will be activated and you will be able to use it as a DevHub to continue your work

You can find more information here: Get Ready to Distribute on AppExchange | ISVforce Guide | Salesforce Developers

Another reason why I think you should switch to PBO fairly early in the project lifecycle is because your listing will be reviewed early and you will avoid the biggest issues that I had.

Branding Guidelines

As some of you might remember, the original name of the project was GameForce. I still think it sounds great, but unfortunately, it goes against the branding guidelines that Salesforce outlines for the applications released on the AppExchange. Specifically, you cannot use "Force" anywhere in your app branding.

To be fair, I suspected that there might be issues when it comes to using some Salesforce logos or mascots, so I deliberately avoided them in my app or even the blog. But I would never suspected that you can't use the words "Force" or "Cloud". Partner guidelines are generally available for the members of the Salesforce Partner Community, but I wasn't a member. I was literally building my app as one huge experiment or a self-growth project at best. So, in the end, I had to rename the app to ScoreHub. It took me a while to come up with the new name because I was so used to GameForce, it was almost as if it was imprinted in my brain at that point. But I am happy with the new name, and I was told that I can only change it as a part of a listing, which I personally thought was not enough. You can imagine, that someone goes to an AppExchange, finds ScoreHub clicks install, opens their Salesforce Org, and under the permission set groups they see groups prefixed with "Gameforce__". Or they try to access some logs or data, and all the fields and objects are prefixed with "Gameforce__" as well, and ScoreHub is not seen anywhere. In the end, I had to create a new namespace (which in retrospect might be a good thing) as well as a new package, update the repository, documentation, etc. It took me a while, so my advice would be for you to check the branding guidelines as soon as possible and definitely before registering a package namespace.

Selecting your pricing model

After the issues with PBO and branding were resolved, the next step was to figure out the pricing model for the solution. It might sound simple - just put a tag on it and that's it, but as it usually happens - the reality is slightly more complex.

My original idea for ScoreHub was to sell it as a subscription with a set of tiers that would include a set amount of user licenses, but also an ultimate tier with an unlimited number of user licenses per org. The assumption was that businesses wouldn't want to fiddle with per-user licenses when it comes to something that is effectively an "extra" and not a "must-have" solution and would be happy to buy licenses in bulk. And while I still think this is the right way to price ScoreHub it doesn't align well with any of the pricing models that Salesforce provides.

When picking a pricing model for the AppExchange listing you have 4 options to choose from. Let's look at each one of them.

Free - the name kind of speaks for itself. This model implies that your app can be downloaded freely, but what is more important is that any third-party service that you use in your app is also free. This means, that for most cases, only a small subset of solutions can actually be considered "free".

Paid Add-On Required - this is specifically a category for the apps, that you are not going to charge your clients for, but you would charge them for the use of the third-party service that they rely on. I understand the idea behind this category, but in my opinion, it exists only to prevent Salesforce from getting complaints from confused customers who have installed an app that was labeled "free" and were requested to provide a license right after the installation.

Paid App - simply put, your app has a price tag attached to it, and after the trial period, users have to pay for it. Sounds good, but this pricing model doesn't allow any wiggle room. No way to set pricing tiers, no recurring subscription and you are forced to use Stripe as a payment provider (which is not bad, but still is a limitation). This is the only model where Salesforce will handle things like getting their percentage of the revenue from you or handling licenses for you.

Freemium - has the greatest flexibility, but requires you to handle everything on your own. You can set pricing tiers, but you will have to invoice your clients on your own. You will also have to track licenses in your PBO to report to Salesforce and pay them their cut of the revenue. There is a whole trailhead dedicated to using the Channel Order App, that you would have to install with the help of Salesforce Support and then configure on your PBO specifically for this reason. To be honest, I was expecting to have a bit more automation on the Salesforce side of things. You are releasing an app in the store, and yet you have to manage licensing and payments. Isn't the whole idea behind app stores that they handle these things for you?

In the end, I had to go with the Freemium model, and set tiers per number of user licenses included in each tier (they would still have to be tracked as per-user licenses on my end though).

Once this was done, the time has come to the biggest challenge of the whole process...

Security Review

The app store distribution model has a great advantage over any other models - it gives users trust in the apps that they are installing. And this trust comes from the fact that each app has to be rigorously tested before it can be released. The more stringent the security process is, the more trust the app store has. Considering that AppExchange is a B2B app store, and apps released there might have a direct impact on the business, they have to be dissected by the security team to avoid even the slightest chance of an issue. Which means, that you have to be ready to pass that dissection.

Security review itself doesn't require much from you - you just wait. But preparation for the security review consists of 4 steps:

1. Scanning your solution using Salesforce Code Analyzer.
2. Running Checkmarx security scan for the package version that you are going to release.
3. Creating a pre-configured test-org for the security team to use for their evaluation.
4. Preparing documentation explaining solution architecture, design, and functionality.

Scanning solutions using Salesforce Code Analyzer is the most straightforward thing out of them, and I would suggest you starting with it. You don't even need to promote your package to release version to do so. You can follow this guide provided by Salesforce: Scan Your Solution with Salesforce Code Analyzer | ISVforce Guide | Salesforce Developers and will end up having 3 .csv files with results. If everything is good - they will be empty, if not - you will have to improve your code to resolve the issues. You can provide a false-positive report to indicate that some of the issues that were found as faulty, but I would strongly recommend against it.

Once you have fixed everything and have your clean reports, you can proceed with scanning your solution using the Partner Security Portal. To do so, you would first need to promote your package version to a "release" state. Which I found a bit silly, considering that new issues might be found during the scan and you would have to fix them, and as a result - create a new package version. So you might end up with multiple release versions that can't be released. It would be nice if Salesforce would allow you to set a package to a pre-release state or something like that, to avoid this. Once you have your package version promoted, you can go to the Security Partner Portal and click on "Request Scan". You have 3 attempts to scan the package version, which doesn't sound like a lot, but after the first scan you will either have a clean report or would have to create a new version, which would have 3 new attempts, so it is not an issue. It doesn't take that long to run the report, but the first time I did that I hit some Checkmarx maintenance window and my request was sitting in "pending status" for 2 days. I was a bit scared to touch it but after a brief conversation with the support team and re-requesting the scan - it went just fine. I think that I was able to fix most of the issues with the Code Analyzer so my Checkmarx scan was flawless from the first try.

As the next step, you must prepare a test org for the security team. Initially, I thought that I could create a Developer Edition org and just install my package there (and it looks like it is a viable option) but then I stumbled upon the recommended way to prepare the test org using the Environments feature of PBO. I think the link to the documentation is available only to the partners so I won't share it here (most of the readers probably won't have access), but it is super straightforward - create a new org from your PBO, install and configure your package, add some test data and you are done. You also have to make sure that you disable 2FA, but the official guide has a reference to the org template that has 2FA disabled already, so you don't have to worry about that.

Last but not least - documentation. I hate useless documentation. And I hate managing documents with useless documentation even more. That is why from the beginning of the project I was managing documentation in markdown files as a part of the repository and only about things I thought might be useful for potential contributors or people reviewing code. But ending those files to a security review team sounded sketchy, so I had to combine all the information about the project, including data structure, class diagram, LWC documentation, etc. into one huge well-structured Word file. This was tedious and time-consuming and made me slightly nostalgic about my years in the uni.

Once everything was prepared, I was ready to submit my solution for a security review. But there was a catch - a 1000$ security review fee. You can avoid this in case you are trying to release a free app, but all paid apps have to pay this fee. And you have to pay it for each subsequent try. So it is not 1000$ per review, but 1000$ per review attempt, and considering that Salesforce themselves say that it usually takes 2 tries to pass the review you should consider the possibility of paying 2000$ per app. I guess that this price is supposed to be a gatekeeper that filters out apps whose creators are not 100% sure of their creation. This is not a big deal for large ISV vendors, but for projects similar to mine, built by a group of enthusiasts this might be a showstopper. I was even considering releasing ScoreHub for free, but I've invested so much time and effort that it just made sense to go all the way through and pay the commission. I've spent extra time and triple-checked everything to make sure I will pass the security review on the first try... And I did!

Final touches

Once the package version was approved by the security team, I was ready for the final approval from the Salesforce manager who was reviewing my listing. This step doesn't require you to do anything really, but it is awesome to have the ability to have an inside into a better pricing strategy or ways to improve SEO for your listing.

I also wanted to go the extra mile and record a set of videos that would showcase the ScoreHub. Even though I prepared the Trialforce template, short videos are easier to process, especially when you are not familiar with the solution.

And that is it! This is how I've managed to release the first version of ScoreHub on the AppExchange. This was an amazing journey and a learning experience for me, and I hope that it was enjoyable to follow. But this is definitely not the end, I still have to figure out how to promote ScoreHub, and I have quite a large backlog planned, so stay tuned!