Custom Settings
Custom settings enable you to create custom sets of data and create and associate custom data for an organization, profile, or specific user. Custom Settings data is exposed in the application cache, which enables efficient access and avoids repeated queries to the database.
The visibility of custom settings can be controlled by making them public or private. If the custom setting is marked as protected, the subscriber organization will not be able to access the custom setting. If it is marked as public, then subscriber org can also access it.
There are 2 types of custom settings: List & Hierarchy, and once you create a custom setting, you cannot change the type from one to the other.
A list Custom Settings provides a reusable set of static data that can be accessed across your organization, & hierarchy custom settings use a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users. In the Hierarchy custom setting for logged-in users, the system first checks the user, the profile, and then the org-wide setting in order to return data from the custom setting.
Considerations
- Custom settings do not support relationship fields,
- Custom Settings have the same permission to edit the records and to edit the configuration. Both can be done with the “Configure Application” permission,
- While migrating a Custom Settings to another org, it only deploys the metadata, you need to upload data into the Custom Settings post-deployment,
- Custom settings can be used by formula fields, validation rules, flows, Apex, and the SOAP API,
- You can perform CUD (Create, Update, Delete) operations on a Custom Setting in Apex, &
- Custom Settings are not visible in any test classes without the “SeeAllData” annotation.
Custom Metadata
Custom metadata works a bit like custom settings but rather than the records being considered as data, they’re actually considered as metadata. Custom Metadata is typically used to define application configurations that need to be migrated from one environment to another, or packaged and installed.
Custom Metadata Types have quite a few more options when being compared to Custom Settings, like picklist fields, long text areas, page layouts, and validation rules.
You can control the visibility of Custom Metadata Types by specifying it as either public or protected. If it is marked as public then anyone can see the data, but if the Custom Metadata Type is marked as a protected type, in the installed managed package, for example, only the Apex code in that managed package can use it.
Considerations
- You can create lookups between Custom Metadata objects,
- Custom Metadata Relationships provides the ability to add relationships from your Custom Metadata to other things in your apps, such as other Custom Metadata, Custom or Standard Objects and fields, and static resources,
- You can edit the records with the “Configure Application” permission, however, in order to edit the configuration you need the “Author Apex” permission,
- While deploying Custom Metadata Types to other orgs, the associated data you created against it is also deployed to the target org,
- You cannot perform CUD (Create, Update, Delete) operation on Custom Metadata Type in apex, &
- Custom Metadata Type are visible in test classes without the “SeeAllData” annotation.