Package platform feature dependencies

Packages can have dependencies on platform features and/or other packages (as previously described). While some features of Salesforce are common, customers can purchase different editions and features according to their needs. Scratch orgs have access to most of these features for free. This means that, as you develop your application, it is important to understand when and when not to use those features (this is done in order to avoid unwanted dependencies that might block or inhibit the adoption of your application).

When referencing a certain Standard Object, field, or component type, you will make a prerequisite dependency on your package, which your customers will need to have before they can complete the installation. Some Salesforce features, for example, Multi-Currency or Chatter, have either a configuration or, in some cases, a cost impact on your users (different org editions). Carefully consider which features your package is dependent on.

As a best practice, to ensure you are targeting the intended features, update your scratch org configuration file and configure it to enable only the desired edition and platform features you wish to be dependent on. You may also want to have multiple scratch org configuration files for different testing purposes, especially if your application code has different code paths depending on a platform feature being enabled or not (as described later in this chapter).

The following example scratch org configuration file enables features relating to Enterprise Edition and, in addition, enables the Multi-Currency feature:

{
    "orgName": "FormulaForce App Testing with Multi Currency",
    "edition": "Enterprise",
    "features": ["MultiCurrency"]
}

Later in this book, we will be discussing Lightning Components. If you are packaging these, you will be implicitly imposing the need for your customers to utilize the Salesforce My Domain feature. This is not enforced at installation time, so it is an optional dependency. However, users will not be able to use your packaged Lightning Components without first enabling and configuring My Domain.

Release and Beta packages

Once you have created your package, it’s good practice to do further testing (sometimes called regression and/or acceptance testing) internally and/or with a selection of customers. This testing may result in the need to make changes that would normally be blocked if the package version had been installed in production. To give you the ability to do further testing and still make changes, packages are either in Beta or Release state, as described here:

• Release: Release packages can be installed in production orgs and can also provide an upgrade path from previous releases. The downside is that you cannot delete the previously released components, or change certain things, such as a field’s type. Changes to components that are marked global, such as Apex code methods and Lightning Component attributes, are also restricted. While Salesforce is enhancing the platform to provide the ability to modify certain released aspects, you need to be certain that your application release is stable before selecting this option.
• Beta: Beta packages cannot be installed in production orgs; you can install them only in other scratch orgs, sandbox, or Partner Portal-created orgs. Also, Beta-managed packages cannot be upgraded once installed; this is the reason why Salesforce does not permit their installation in production orgs. The key benefit is in the ability to continue to change new components of the release, to address bugs and features relating to user feedback, after which, you can create another Beta version. Note that Beta unlocked packages can be upgraded.

Package versions are, by default, in Beta state. In order to promote them to Release, you need to run the following SFDX CLI command:

sfdx force:package:version:promote 
  --package "FormulaForce [email protected]"

Optional package dependencies

It is possible to make some Salesforce features and/or base package component references (Custom Objects and Fields) optional aspects of your application. There are two approaches to this, depending on the type of feature.

Dynamic bindings

For example, the Multi-Currency feature adds a CurrencyIsoCode field to standard and Custom Objects. If you explicitly reference this field, for example, in your Apex code, Lightning pages, or components, you will incur a hard dependency on your package. If you want to avoid this and make it a configuration option (for example) in your application, you can utilize dynamic Apex and Visualforce. Lightning value bindings are dynamic in nature, though the aura:attribute element type references will form a compile-time reference to the specified objects.

Dependent packages

If you wish to package component types that are only available in installation orgs of certain editions, you can choose to include these in dependent packages. For example, you may wish to support the Professional Edition, which does not support record types. In this case, create an Enterprise Edition dependent package (as outlined above) for your application’s functionality, which leverages the functionality from this edition.