0

I'm shipping a managed package that will include a lightning app with a few lighting components to configure some "master org level settings". I have an external application that will need to query these settings as needed. Most of these settings are simple booleans and strings. So the lightning app should have access to them and they should be available though the web API.

Where is the best place to store these settings?

It looks like Custom Settings could work for this purpose but wanted to make sure this is the best option as the data types seem a bit limited (strings limited to 255 chars for example).

3
  • Are your 'simple booleans and strings' longer than 255 chars?
    – identigral
    Sep 5 '20 at 17:33
  • the string could be. what I meant by that is no complex types like lists.
    – rosghub
    Sep 5 '20 at 17:40
  • Complex data types such as lists are not available on any Salesforce object type, saving the much-maligned multiselect picklists.
    – David Reed
    Sep 5 '20 at 18:06
1

You've got three choices:

  • (Hierarchy) Custom Settings. These get you configurability at the level of a single user or profile, if that is desired. They're easy to manipulate in response to user configuration. They're data, so you can't ship the record content in the package. You can also choose to mark them Protected, meaning they can be accessed only by your packaged Apex code.
  • Custom Metadata. Unlike Custom Settings, Custom Metadata records are metadata, meaning you can package and ship the record content with your application. Because they're metadata, manipulating them in code is somewhat more complex and limited. They also offer unique features like relationships to schema entities. Custom Metadata can also be Protected, and as such is the most appropriate feature for managed package secret storage when you need to ship a secret value.
  • Custom Objects. You can choose to use regular old Custom Objects to store application data, which don't come with any of the special features of Settings or Metadata, but allow you to take full advantage of all available data types (including Long Text Areas, where you can store e.g. JSON values) and the Salesforce security model. Custom Objects can also be Protected.

All of these options are the right choice for specific applications, based on the exact requirements. Based on what you've told us, Hierarchy Custom Settings sound like they are a strong candidate, but you'll have to evaluate each against the full scope of your application's needs.

6
  • As far as shipping the 'data' with the package, basically I need to ship default values. I'm not interested in having multiple configurations for different profiles, just one configuration for the entire org. So if I've created a custom hierarchy setting and set a default org level value, you're saying I cannot ship this values in the managed package?
    – rosghub
    Sep 5 '20 at 18:25
  • No, you cannot. Your code would have to supply any defaults desired.
    – David Reed
    Sep 5 '20 at 18:26
  • Would that be as simple as an insert statement in a post install script? Or does it sound like custom metadata would be a better option?
    – rosghub
    Sep 5 '20 at 18:27
  • 1
    You can certainly make it work with Custom Settings by creating your defaults at need (remember too that the user can delete the records at any time, so a postinstall isn't necessarily all you need).
    – David Reed
    Sep 5 '20 at 19:10
  • thank you for the explanation; quick question on the 3rd option of using custom objects, how would that look? Would I basically create a custom 'AppSettings' object and define my custom fields, and there would be one master record holding the app settings? Wouldn't this also share the drawbacks of Custom Settings in that 1) the data can't be packaged and 2) the user could delete it?
    – rosghub
    Sep 5 '20 at 21:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.