img1

Prologue

Salesforce developers are tasked with the requirements in designing and developing custom-built applications on the platform using the APEX programming language. Not just developers though, administrators are also tasked to create custom applications with hardcoded data on the platform. Hard coding data is considered an anti-pattern, this is mainly because hard coding requires the application source code to be changed any time the input data or desired format changes. This then creates the problem of accessibility, because various users might not have proper access, hence dependency on the original implementors to make a change upon request, which in itself is not a maintainable process as the application grows and scale with new business requirements.

Definition

The solution is to leverage MetaData, but what is this magical word? Metadata can be explained in a few ways:

  • Data that provide information about other data
  • Metadata summarizes basic information about data, making finding & working with particular instances of data easier

In simple terms, metadata is a shorthand representation of the data to which they refer. If we use analogies, we can think of metadata as references to data. Think about the last time you searched Google. That search started with the metadata you had in your mind about something you wanted to find. You may have begun with a word, phrase, meme, place name, slang to look up specific information. Google in is this case, helps to organize, find and understand data in your mind 😥😲😀

Solution

Salesforce understood the need to declaratively create MetaData with the intent of eliminating hardcoding on the platform. Two unique, related but separate solution was created. Namely Custom Settings and Custom Metadata Types.

Custom Settings

Custom Settings allows developers and administrators alike to create custom sets of data in addition to creating associating custom data for a user, profile and organization on a whole. Custom settings are similar to custom objects but not as powerful. Visibility for custom settings can be set only in a developer or scratch org. The visibility setting affects objects released in managed packages. Protected custom settings aren’t accessible by a subscriber’s org, but public custom settings are.

Benefits Custom Settings

  • All custom settings data is exposed in the application cache
    • this enables efficient access without the cost of repeated queries to the database
  • Custom settings data can be used by formula fields, Visualforce, Apex, and the Web Services API

Disbenefits Custom Settings

  • Data stored cannot be migrated in packages(not data) or Metadata API tools
  • Though similar in capabilities to custom objects, fewer field data types are available to use
    • Checkbox, Currency, Date, Date/Time, Email, Number, Percent, Phone, Text, TextArea, URL
  • There exist no way to relate a Custom Setting to a Custom Object
  • There are no page layouts available
  • There are no record types available
  • You cannot define Validation rules, Workflow rules
  • Cant create triggers

Types Custom Settings

List Custom Settings

A List Custom Setting is very similar to how Custom Object work, the data does not vary between users or profiles and is available across the entire organization. It provides a reusable set of static data that can be accessed across your organization. If you use a particular set of data frequently within your application, consider using this Custom Setting type.

Hierarchy Custom Settings

As the name might have implied, Hierarchy Custom Settings uses hierarchical logic to personalize settings for profiles and/or users. The hierarchy logic checks the organization, profile, and user settings for the current user and returns the most specific, or “lowest” value in the hierarchical rank.

Custom Metadata Types

Custom Metadata Type is another way Salesforce can store and manipulate Metadata. Put more systematically, Custom metadata is customizable, deployable, packageable, and upgradeable application metadata. Developers and Administrators can then create reusable functionality that reads custom metadata and uses it to produce customized application behavior. You can use Setup to create, update, and delete custom metadata types and records declaratively. Use the Metadata API to perform these tasks programmatically.

Notes

  • Custom metadata types have a suffix of __mdt (instead of __c for custom objects)
  • Custom metadata type field names have a suffix of __c, like other custom fields
  • Names of custom metadata types must be unique within their namespace

Benefits Custom Metadata Types

  • Traceable (Setup audit trail history)
  • Retains much of the same capabilities similar to that of Custom Objects
  • Ability to create relationships to relate records
  • Simple, automated package upgrade process
  • Data can be migrated
  • Querying custom metadata records doesn’t count against SOQL limits
  • Can be deployed using Changesets
  • You have greater control over the visibility of custom metadata types; you can hide the custom metadata types themselves or just hide specific records
  • You can control whether or not users can update record values on a field by field basis
  • You can package custom metadata types and records in unmanaged packages, managed packages, or managed package extensions

Custom Metadata Types Limitations

When using custom metadata types, be aware of these special behaviors and limitations.

  • Custom Metadata Types do not support permission set muting
  • You can reference up to 15 unique custom metadata types in all validation rules per entity. For example, Account object validation rule combined you can only reference up to 15 different custom metadata types
  • Custom Metadata Types do not support Shield Platform Encryption for fields
  • Global picklists aren’t supported on custom metadata types. You can only use sObject picklists 😑
  • Subscribers can’t add custom metadata records to installed custom metadata types that are protected. To allow subscribers to create custom metadata records, the custom metadata type must be public.
  • Fields per custom metadata type or record - 100
  • Custom metadata types per organization - 200
  • Records returned per transaction - 50,000
  • You can use ORDER BY only with non-relationship fields
  • You can use ORDER BY, ASC, and DESC with multiple (non-relationship) fields
  • You can only use ORDER BY when the ordered field is a selected field
  • You can add a custom metadata type that has a picklist field with inactive values to a managed package, but you can’t upload the package. To upload the package, delete or reactivate the picklist values
  • Subscribers to a released managed package that contains a custom metadata type with a picklist field can’t add, delete, or deactivate values from that picklist
  • Developers who release a managed packaged that contains a custom metadata type with a picklist field can add picklist values but not delete or deactivate them
  • Custom metadata types cannot replace hierarchy custom settings which allow you to vary values based on users and profiles across the org
  • Custom setting record’s values can be edited in code, while custom metadata cannot. If you will need to modify your configuration programmatically for any reason custom metadata will not work

Epilogue

Thanks for reading and i hope that you now understand to an extent the Metadata tools, limitations and benefits on the Salesforce platform. This article was mainly focused on concepts and the overall description for Custom Settings and Custom Metadata Type. I will be subsequently releasing another article detailing the different ways in APEX and validations(formula’s) rules etc how you can interact with the different Metadata functions in the system.