Ytdyklly

We are working on an application in managed package, and we need to store app configuration. Generally, we want to allow users to turn on/off some features in our app. For example, on the settings page (visualforce page) there will be a checkbox "Allow <something>" that users would use to enable/disable functionality that our app provides.

What we need basically is:

1. Have a set of default settings for an application (this should be available right after the app was installed)


2. Allow end users (in a subscriber org) change those default settings at any time

So there are quite a few options how we can address this: (1) constants in apex class; (2) custom objects; (3) custom settings; (4) custom metadata types.

While all of these options can get us what we need, Custom Metadata Types seems a better choice. It's newer than Custom Settings, more flexible, and its values can be shipped with application directly, reducing the need apex install scripts to populate values. Still Custom Metadata Types has some limitations, e.g. record values cannot be updated in Apex (or am I wrong here?).

Hence I have several questions:

1. This is a high level question concerning design and architecture overall: What is a common approach to store app settings for a managed package application? Are there any design patterns?
   


2. If Custom Metadata Types was our go-for option, how would we update record values? Taking my example above, how would I store the value of "Allow <something>" checkbox to the database?

I would pretty much entirely dismiss

1. Constants in apex class: It's not possible for the end-users to modify them; they're not good practice anyway)


2. Custom objects: Can't ship them, end-users can't deploy them. You're wanting to store metadata and the platform intends you to use Custom Settings or Custom Metadata for that


3. (a) List Custom Settings - These days, Custom Metadata is better in almost every way

Which leaves you with

3. (b) Hierarchy Custom Setting - Useful because they are per-user, and for storing lots of different settings together. Bad because you can't package the values, and the end-user can't deploy them


4. Custom Metadata - the best option if you can make it work. You can package the values, and end-users can deploy them.

The downside of Custom Metadata is that you have to use the Metadata.DeployContainer and similar classes to write to them from Apex and this has to be done asynchronously. Nevertheless, you can write a Visualforce page, or Lightning Component to make this relatively easy for your end-users.

See https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Metadata_CustomMetadata.htm for details.

One option missing here is Custom Permissions

For your example, Custom Permissions might be a good fit because it is a boolean enable/disable option. If you want by default to allow a feature, you could have a custom permission called DisableXYZFeature that can be applied via profile or permission set. If each of your custom settings are of this nature, it would also eliminate your need to build a configuration screen, as it would be controlled through the platform's Permission Set and Profile setup screens.