An urban legend says the Salesforce release process needs a break in the fall just to come back in winter with double the energy than usual. There might be some truth in that, so we were excited to check out the new release notes to see for ourselves. There are three major release features around Packaging that we were the most excited about because they will simplify the process of package creation and open a way for adding more customizations. As your trusted PDO partner, have provided you with an overall rating of each feature. Let’s get into it!
Transfer package ownership to a different dev hub - 2/5 rating
Transfer. Package. Ownership. These three words make our hearts skip a beat. This is a huge pain point in the world of Product Development Outsourcers (PDO). There is a lack of ability to give the Independent Software Vendor (ISV) a customer namespace at the very beginning of the project before they have a Partner Business Organization (PBO) registration in place which can cause much frustration.
At first, we thought that this functionality is the solution to the problem, meaning we at Aquiva Labs would be able to create a package using our DevHub environment and any namespace and then be able to transfer it to the ISV customer easily. Sadly this is NOT the case even though this feature is technically able to do such a transfer. According to the information we have managed to gather, applications of this functionality are limited to acquisitions, product spin-offs or genuine mistakes when associating dev hubs. You can check this Twitter thread where our PDO Architect discussed this issue with the Salesforce team.
This doesn’t mean that it’s bad news. Both Aquiva Labs and our clients have extra flexibility given by Salesforce when needed. We just wish it would be extended to other, more down-to-earth and frequent scenarios. We currently don’t have any information that would suggest Salesforce will extend the application of this feature. For now, the process involving package ownership remains the same as it was for us and our clients. Fingers crossed that they make this a reality in the next release!
We could speculate why Salesforce is limiting its functionality to corner cases. One could argue that this way the applications are somehow more secure and others would say that this would be too risky for the business from Salesforce’s perspective to simply give the ability to transfer package ownership. Either way, we feel a bit disappointed, because this is not the way we thought transfer package ownership would work.
Understanding component behaviors in Managed Packages - 4/5 rating
You cannot talk about managed packages without mentioning security. It is hands down one of the most important factors in the area and one of the reasons they are so special. It is simply very hard to break something terribly from version to version. In its current state, Salesforce won’t let you delete a piece of metadata, which is necessary for the system to work properly. As you can imagine, this can be a problem.
Back in the day, we didn’t have one specific piece of documentation which would clearly state which action can be done by which party. For instance, there wasn’t a single document which would list all package-related details of arbitrary Metadata type, e.g. that:
- List Views can be modified by both the subscriber and package developer
- Apex Triggers cannot be deleted by subscribers but the package developers can remove them from the package
- This List could go on forever
What we had in place were a series of official and unofficial documents which attempted to gather this information. Now they are not needed, since Salesforce has released a document which aggregates all that information. We finally have a place to go and check what we can do with the packages without piecing together different options.
At Aquiva Labs, we believe there is value in having a better understanding of the product and its capabilities and structure. This applies to both us and our clients. We can both benefit from it. If you are working with the AppExchange applications on a daily basis we recommend one thing: open this link and add it to your bookmarks. You will thank us later.
Implement more feature parameters - 5/5 rating
Have you ever wondered how you can activate new features directly from your Partner Business Org (PBO)? Or maybe you were thinking about getting some insight into customer activation metrics. Thanks to this release, Feature Management App (FMA) is here to simplify that demand.
FMA is an app inside your License Management Org (LMO), which in most cases will be your PBO org too.
In LMO you have License Management App (LMA) which is responsible for helping developers and publishers apply licenses to their uploaded and registered AppExchange apps.
We know, there are a lot of orgs, apps and shortcuts. It can be hard to quickly get used to it, so here is a quick reminder:
- PBO (Partner Business Org) – main partner org, provisioned after registering in Salesforce Partner Program
- FMA (Feature Management App) – an app that is responsible for tracking feature parameters
- LMO (License Management Org) – org that contains LMA
- LMA (License Management App) – an app in LMO that is tracking licenses of your apps
- The license management process begins when someone installs an app from AppExchange. This is where the magic happens.
Salesforce will now automatically create a license in the subscriber org, and a copy of that license in the developers’ LMO. This way developers and publishers can see orgs that are using their package, with the installer’s name, company and email address stored in a Lead object.
Right now we just have covered all the knowledge needed to fully understand Feature Management App possibilities. FMA is used to have “interaction” with your customer’s orgs. But how does this “interaction” happen?
And here comes another fancy name – Feature Parameters. Feature Parameters are represented as Metadata API types and store boolean, integer or date values. They are directly related to your package and hold the name, data type, and data flow direction. Data flow direction determines the direction of data flows – can flow to the subscriber org or to the LMO.
When your customers install your package for the first time, a FeatureParameter__c record is created in your LMO for each Feature Parameter that has been defined.
This way we have the option to create premium features for our customers that would be enabled or disabled directly from our LMO (using Feature Parameters).
Before the Winter ’23 release, we were eligible for 25 feature parameters in org. A lot of publishers have a hard time with that since this is a rather small amount of flags per package. They run out of them quickly and need to think about some workarounds to make sure they can still grow and add new features.
With this release, we get this limit increased from 25 to 200 which is 8 times more! For some publishers, it would still be less than expected, but for most AppExchange apps, it should be really good news, and there is always a possibility to discuss with salesforce the possibility of increasing this limit.
If you would like to read some more regarding this interesting topic, you can do it here.
Why we love Salesforce Releases
New features added by Salesforce in the Winter ’23 release are for sure the right steps for better AppExchange development. We now have the ability to transfer package ownership in some corner cases, clearly see what we can do with the metadata we have already included in our package, and can now easily develop more features with extended limits.
If you would like to know more about the Winter ’23 release, or about AppExchange solutions, please feel free to contact us today.