I am working on a managed package application and I need to store some configuration data. This data is supposed to be edited by admins in the subscriber org. The setting simply stores information about SObjects and their fields which my app can work with. Admins can then configure it via a custom configuration page provided by the app. So, I basically need CRUD operations for this setting.

Initially, I thought of the data structure as a list of records. Each record would store SObject API Name and corresponding field names selected by admin. Later, when I decided to use Custom Metadata Types (CMT) (see my reasoning below) I had to store everything in the JSON format. This is because CMTs do not support the delete operation on records.

So, why did I choose Custom Metadata Types for this task:

  • List Custom Settings are disabled by default and it feels like SF will deprecate it soon, so I didn't want to use it in a new application.
  • Custom Objects are not generally the best choice for storing app configuration (they can be accessed by non-admins; count towards DML/Query limit; etc.)
  • CMTs, on the other hand, are intended to be used to store configuration data
  • Salesforce advocates to use CMTs instead Custom Settings.
  • There are plenty of examples of how to use CMTs records for editable settings:
  • CMT provides the Long Text Area field type which is better for my case JSON string will obviously exceed 255 chars.

Unfortunately, when I implemented CMT solution, I faced a problem that updates to the metadata records failed randomly resulting in Fatal Error deployment status. Sometimes deployments were successful, sometimes not. More on this issue in my previous post - Metadata.DeployCallback is not called when deployment status is Fatal Error. Note: I tested this in scratch orgs with a namespace.

As you can see, CMT appeared to be an unreliable solution in my case. I really want to believe that this is not a SF bug, but a flaw in my implementation. Nevertheless, I couldn't find what causes this random deployment fails. And this is awkward actually, if there was a bug in my implementation, I wouldn't even be able to deploy CMT records at all.


Now I have to find another solution. So I am wondering if List Custom Settings is a good choice for my need? And is it a good design decision for the long term?

  • Which way did you go?
    – ondrakr
    Jun 27, 2021 at 9:37
  • We used CMT approach in the end. The issue didn't reproduce in production and in org where the package got installed.
    – Eduard
    Jun 29, 2021 at 11:26


You must log in to answer this question.

Browse other questions tagged .