34

We've always been conservative when it comes to exposing Globals for use by extension packages or subscriber extensions, and perhaps too conservative. We're considering being more proactive wth our global architecture, and we're discussing several changes to our current practice, in order to create a new set of best practices.

Topics we're discussing include "microglobals" that all share a common interface, minimizing the call tree, and when and how much we should use the internal API versioning that Salesforce provides.

Do you already have a set of best practices for designing and maintaining globals that works well for your packages and that you could share?

Improve this question
9
  • Though I can see this being somewhat opinion based I would think this can be turned into a useful Q&A with a little work, so voting to leave open.
    – Dave Humm
    Mar 5, 2017 at 14:57
  • Thank you, @DaveHumm. While a great number of practitioners use extension packages to provide additional functionality and modularity, Salesforce only discusses extensions as a way to support multiple editions. As a result, there is no guidance in the Salesforce documentation that covers real-life practice.
    – Ted Husted
    Mar 6, 2017 at 16:24
  • 2
    Note that Salesforce is planning to make significant changes to the packaging process over the next several releases, so that may change best practices over time. This DF16 presentation should give some more insight if you haven't seen it. I believe they are planning to allow you to develop extension packages in the same org as your main package, which should remove the necessity to make classes and methods global solely for extension packages (safe harbor, of course).
    – Robert Watson
    Mar 8, 2017 at 1:00
  • Honestly, @RobertWatson, the pkg 2.0 changes will call for even more discipline in our practice, since we'd be able to share publics between artifacts. Brrrr.
    – Ted Husted
    Mar 9, 2017 at 13:59
  • 1
    Here are some practice notes from another thread. * Prefer API-first, even if it means more globals. * Prefer use of interfaces and class extensions. * Prefer static stateless methods on services with the use of DTOs. * Establish an API Review process. * Enforce strict naming conventions, especially on API elements. * Prefer Invocable Methods as an API strategy. * Avoid the Salesforce behavior versioning. * Prefer versioning through introduction of a successor class (Global2, Global3). * Consider injecting @deprecated when deploying to packaging orgs.
    – Ted Husted
    Mar 9, 2017 at 14:00

1 Answer 1

Reset to default
1

This is not an attempt at answering holistically but to share my current best practices. I want to update this answer if things change.

As of Winter20 unlocked packages are not yet available for ISVs. Even with shared namespace, @namespaceaccessible, ..., access got restricted again. More methods/classes need to be global due to security concerns if they live in different packages.

On the up-side, providing Field Level Security is much less of an headache with new features like WITH SECURITY_ENFORCED for SOQL becoming GA with Spring20.

There are currently two best practices I think fit everyone:

  • always add (empty) constructors to global classes

    The engine will always add one if there is none present and should you decide to release your own constructor in the future, package upgrade will fail because the hidden global constructor is attempted to be overwritten.

  • make method arguments generic: myGlobalMethod(Map<String,Object> params) {}

    This give you the flexibility to change implementation details after initial release.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .