We're moving towards the package development approach instead of the current monolith org. We'll also be using scratch orgs and CI/CD. The most important and tricky part that I'm facing right now is, how to break down custom fields into packages the correct way. So if a custom field is referenced in multiple locations in the code and then it'll be referenced in multiple different packages.

  • Do I put these custom fields into their own packages (custom fields package)?
  • Do I put a custom field in package1 and the other packages would need to reference package1? Is this efficient and does it follow best practices (what are the best practices?) I think this becomes an issue if anytime a package needs access to a field it has to include this package1 where a lot of metadata is loaded in that isn't needed.

I appreciate any recommendations, best practices, etc.

I've used these references so far:

  • 1
    I doubt there is much Salesforce-focused on this topic, the architects site has some articles on package development: architect.salesforce.com/deliver/release-management-templates/… If Salesforce documentation is lacking, there are resources on software engineering that would be of help. Look for "modular design", because one of the first things you'll undoubtedly run into is code and metadata that is tightly coupled and splitting things into packages is likely going to entail a lot of refactoring to spread things out into features.
    – nbrown
    Feb 23, 2021 at 22:15
  • @nbrown thanks this is great information. I also appreciate if you point me to any specific software engineering pages that you've found useful.
    – Bahman.A
    Feb 23, 2021 at 22:18


You must log in to answer this question.