When starting Salesforce package development, there are several important architectural decisions that need to be made early on as well as some considerations to keep in mind as you develop your product. Dedicating time upfront to this will help set good foundations for your application and give you the confidence to go into security review and distribution. Make sure to read through and get familiar with the concepts in the ISVForce guide that Salesforce has developed as a guide to package development.
OEM vs ISV Packages
First you need to determine which type of application fits your business and your use cases. OEMs are complete applications developed on Salesforce that are limited in what standard objects they can use but enable customers to resell Salesforce user licenses and set up their customers’ orgs. ISV applications are intended to be add-on packages to existing Salesforce installations. More detail on both can be found in the ISVForce guide. This decision will drive the app’s architecture and decisions from the start so make sure you know clearly which direction you will be taking.
One or Many Packages
In most cases, you will only need one package but there are a few reasons to go with multiple packages. You could be developing some features that will only work with a certain industry cloud and don’t want to make your base package dependent on that cloud for example. You could get away with dynamic coding for some scenarios, but any hard references in the package would make that impossible. Additionally, if you’re going to be making different “products”, you should consider multiple packages for reasons such as code clarity, maintainability, and sales/marketing. Currently, Salesforce does require that each package go through the security review process independently which can add overhead to multi-package solutions so be mindful about choosing a multi-package approach without a compelling reason.
First and Second Generation Packaging
If you are just starting out with Salesforce package development, you should likely use 2GP (Second Generation Packaging). There are some scenarios where you can’t, such as when you are reliant upon a feature that isn’t available in scratch org development, but you should if possible. It has benefits such as multiple packages available with a single namespace, namespace accessible methods, source control as your source of truth, package branching, and more that is lacking in 1GP. However, if you are already familiar with and using 1GP packaging at your organization, it may make sense to continue with that pattern assuming there is already knowledge and tooling in place that would be costly to change. 1GP to 2GP conversion is being worked on at Salesforce but will take some time to come.
Namespacing and Governor Limits
With managed packages, you need to be aware of how namespacing and governor limits work. Namespacing is Salesforce’s process for securing packages and allowing for them to coexist in the same org. Each package can have a field named “Email” only because of the namespace assigned to each for example. Additionally, code can generally only be executed within a namespace unless it is marked as global. Along with this partitioning, limits are generally enforced per package once they have passed security review. So your trigger can query for up to the maximum number of rows allowed by governor limits and another package can do the same. However, some limits are enforced at the org level regardless of packages or namespaces. These include things such as numbers of custom fields allowed per object, API and Platform Event limits, numbers of External Ids, and more. When developing your package, you must be aware of what these limits are and be respectful of the impact on your customers. Additionally, if you expect to be dealing with large data volumes, you should pay particular attention to limits and query optimizations.
You also need to set up your devhub and choose a namespace. The devhub ultimately needs to be your PBO (Partner Business Org) but you may not yet have that available as it needs a signed partnership agreement with Salesforce. So to start you may just need to start up a trial devhub and associate your namespace with it there. To create a namespace, you need a developer edition org and register it there in the package management settings. Once done, you need to link it to your devhub as a namespace registry to make it available to your package(s). This namespace cannot be changed but it can be replaced up until your security review submission so feel free to make a throwaway namespace so you can use namespaced scratch orgs and trial packages. Once your PBO is ready, enable devhub in it and use that as your packaging org. You cannot submit a package in a trial devhub to security review so you will eventually need to get that done. However, with the recently announced ability to transfer packages between devhubs, this and the temporary namespace may not be as big of a concern for much longer.
Development Org Strategy
When developing a package, you have two main options: Sandboxes and scratch orgs. For most package developers, scratch orgs will be the best choice but there are benefits to sandboxes as well. Sandboxes are necessary when you are developing against features that aren’t available in scratch orgs for example. They are also able to copy some data from a source org which can help with data setup. However, scripting data setup would be the better choice for most. Either way, you will want to use source control combined with Continuous Integration to run tests and deploy code to persistent environments. Those persistent environments, as well as sandboxes, cannot be namespaced while scratch orgs can use the package’s namespace. Being able to use namespaced scratch orgs for development and non-namespaced orgs for testing also lets you catch many namespace issues before package testing.
Security Review
When doing development, make sure to always keep security review in mind. You must enforce CRUD/FLS and Sharing where appropriate for example along with items such as absolute positioning in css amongst a number of potential vulnerabilities. Use the Salesforce provided source code scanner or other method of scanning your code often to try to catch any issues that make it through code development and pull requests. This is important because it will be much harder to retrofit those changes rather than developing a secure package from the start.
In order to submit to security review, you must have your partnership agreement signed and your PBO setup. Start this process earlier than later as it can take a while to finalize your partnership agreement. Once that’s done and your development is complete, you will run through a security review questionnaire which asks questions about your application such as what integrations it has,, what types of components you use, etc. You can also request security review office hours if you have questions for the SecRev team. Once submitted, it usually takes a few weeks for the app to be reviewed.
Need help with your designing or fixing your package architecture? Struggling with Security Review? Let’s talk.
Rob Davis, Technical Architect
