Custom Metadata types - Time to say goodbye to Custom Settings

-
I was creating custom settings to store some configuration data. Clicked on the New button, and the custom setting creation page gave me a tip saying:


Tip: Use Custom Metadata Types for App Configuration

If you're thinking of using list custom settings, consider using custom metadata types instead. Unlike list custom settings, you can migrate the records of custom metadata types using using packages or Metadata API tools.

That's when I came to know about the great features which Custom Metadata Types provide. Custom Metadata types are similar to Custom Settings with an added advantage that you don't have to load data post deploying them. The data in Custom Metadata type is stored as metadata and not data. So when you deploy Custom Metadata types, the data is also deployed along with it. Let's do quick comparison between Custom Metadata Type and Custom Settings and try to figure out when to use what.

1) Data: As mentioned above, data is stored as metadata in Custom Metadata Types. So when you migrate a Custom Metadata Type from one sandbox to another or from sandbox to production or refresh a sandbox from production, the data moves along automatically. If you use Custom Settings here, you have to perform a data load for each of these cases. Sounds great? Well wait, there's more to come.

2) Testing: Custom Metadata Types are visible in test classes with seeAllData=false for the obvious reason that data is stored as metadata. If you use Custom Settings, you have to explicitly create data for your custom settings in test class.

3) Accessibility in Apex: You need to do a SOQL query to access Custom Metadata types in apex code. But do not worry, these SOQL will not be counted against your governor limits. You can take advantage of all SOQL functionality such as ORDERBY which you cannot leverage while using Custom Settings. Custom Metadata types have a suffix of __mdt instead of __c present for Custom objects.

4) Who can edit records: If you are using custom settings, the org admin can do a data upload for Custom Settings and can also create/edit/delete records manually. The access to Custom Metadata Type records is decided by a parameter called "Field Manageability" which as 3 options: Only the package developer (via package upgrade), Any user with the Customize Application permission (package upgrades won't overwrite the value) and No one.

5) Limits: You can have 100 Custom Metadata Types per organization. This number includes all types developed in the organization and installed from managed and unmanaged packages. Custom settings are a type of custom object. Each custom setting counts against the total number of custom objects available for your organization.
100 fields are allowed per Custom Metadata Type. The number is higher for Custom Settings: 300 fields per custom setting.
The amount of data allowed for both Custom Metadata Type and Custom Settings is 10 MB.

Comments

Post a Comment

Popular posts from this blog

Salesforce Lightning: Countdown timer

-
Image
Today we will have a look at how to create a lightning component for countdown timer which can be used on pages where an operation needs to be completed within a specific time period. Example, an online exam or a banking transaction which expires after a specific time period. The component contains a datetime field which represents the end time. Once the user selects the date and time and clicks on Start Timer button, the countdown timer will start. Below is the lightning component: CountdownTimer.cmp <aura:component implements="force:appHostable,flexipage:availableForAllPageTypes,flexipage:availableForRecordHome,force:hasRecordId" access="global" >       <aura:attribute name="endTime" type="String"/>       <aura:attribute name="timeLeft" type="String"/>       <lightning:tile label="Time Left" class="slds-page-header">         {!v.timeLeft}     </lightning:tile>
Read more

Salesforce Hacks: System.LimitException: Too many queueable jobs added to the queue: 2

-
Queueable classes are great to use and provides a wide range of advantages when compared to future methods. But there are some undocumented limitations which you will come across if you are using Queueable classes extensively inside your batch classes. Lets take an example of badly written trigger on Account.  trigger AccountTrigger on Account (before insert) {     for(Account acc: Trigger.new){         Database.executeBatch(new CreateContactBatch(), 2);     } }   The above trigger calls a batch class for every account record that gets inserted in database. So if you insert N accounts in a single transaction via dataloader or anonymous block or through any other means, the trigger will execute the batch class N number of times. Below is the code for batch class: global class CreateContactBatch implements Database.Batchable<sObject> {          global Database.QueryLocator start(Database.BatchableContext BC) {         String query = 'SELECT Id FROM Account'
Read more

Building an Org Role Hierarchy component in LWC

-
Image
You might have observed that the role hierarchy which gets displayed in the org (Setup > Users > Roles) is still displayed using a VF component. Today, we will see how to create the same role hierarchy using LWC and Apex. LWC provides us with a component called lightning-tree which displays a nested tree. We will make use of this component to display the role hierarchy in a tree structure. In Apex, we will query all the user roles and form a JSON structure which will be fed to the lightning-tree component. Let's first see the LWC component - roleHierarchy: roleHierarchy.html <template> <div class="slds-p-around_medium lgc-bg"> <lightning-tree items={roles} header="Roles"> </lightning-tree> </div> </template> Here we have used the lightning-tree component which will display the data in a tree structure. The items attribute is of type Object which has nested i
Read more