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?

Your Answer

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

Browse other questions tagged or ask your own question.