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).

Improve this question
3
  • Are your 'simple booleans and strings' longer than 255 chars?
    – identigral
    Sep 5, 2020 at 17:33
  • the string could be. what I meant by that is no complex types like lists.
    – rosghub
    Sep 5, 2020 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, 2020 at 18:06

1 Answer 1

Reset to default
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.

Improve this answer
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, 2020 at 18:25
  • No, you cannot. Your code would have to supply any defaults desired.
    – David Reed ♦
    Sep 5, 2020 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, 2020 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, 2020 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, 2020 at 21:24

You must log in to answer this question.

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