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?

2 Answers 2


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

  1. (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
  2. 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.

  • 2
    List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
    – sfdcfox
    Commented Jan 10, 2019 at 15:28
  • I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
    – Aidan
    Commented Jan 10, 2019 at 16:13
  • Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
    – Eduard
    Commented Jan 10, 2019 at 17:17
  • I cannot update custom metadata : salesforce.stackexchange.com/questions/253867/…
    – Abhishek
    Commented Mar 14, 2019 at 14:14

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.

  • That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
    – Eduard
    Commented Jan 10, 2019 at 17:15

You must log in to answer this question.

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