Friday, September 9, 2016

Salesforce Custom Metadata Types - Application Configuration Magic

Introduction


Metadata is data about data, .i.e. it is data that describes data. An account for instance, can be described by its name, location, number of employees, annual revenue etc. This is information that describes an account in general.

As of Summer release 15, Salesforce has given us a way to be able to create our own custom metadata type. Now why would you want to do this? One reason alone is very compelling. So you can stop putting application configuration data in custom objects or list custom settings, both of which have the huge limitation that you can't deploy or package them. With Custom metadata types, you can deploy the records you create from them as part of meta data. Yes you heard that right. Custom Metadata Type definition and records can be packaged and deployed as part of metadata.

So Custom Metadata Types are truly a special kind of metadata because similar to custom objects, they can have fields which describe records created as part of the Custom Metadata Type. These fields constitute metadata and will be deployed. But the cool part is the data or records created from the Custom Metadata Type Definitions are also considered as meta data and will be deployed as well. No need for manual error prone and expensive processes for transferring these records from one sandbox to another or to prod. This covers the customisable and  deployable advantages of Custom Metadata Types.

Another advantage that is more relevant to ISVs ( Independent Software Vendors) is that Custom Metadata Types are packageable and upgradeable. Normally with application configuration data in custom settings of custom objects, ISVs will have to run complicated post install scripts to create configuration records on their customers orgs. NO MORE
Another advantage depending on how you look at it, is the ISV's ability to create his metadata types as protected, meaning they are locked and can't be modified by customers downloading the package.

Let us look at an example of how to create a custom metadata type.

Example


Use case 


Build an email editor whose look and feel is customisable by region of running user. Regions are AMER, EMEA, LATAM, APAC.

Solution 


1.)  create an object ( metadata definition ) for our custom metadata type by going to Setup -> Develop -> Custom Metadata Types. Click on New Custom Metadata Type



Note the radio button "" An ISV can choose to limit the access of the custom metadata type only to the managed package, meaning the user who installs the package or any other code in his org will not be able to see and use this custom metadata type.

Add a few fields to the object you just created to define what aspects of the editor you will like to customise. Could look something like this;



Now click on "Manage Email Editor Configuration" to add records for the different regions. Remember that the beauty of Custom Metada Types lies in the fact that the object definition and the records are deployable and packageable.

Custom Metadata Types also have layouts that you can customise like normal custom object page layouts;




If you are creating records manually, use the clone button. Will save you tons of time especially if the configuration records differ only minimally from region to region


Protected

Notice that you can also set the records as protected. This simply means that only code that is in the same managed package as the protected record or the Custom Metadata Type to which the protected record belongs can see and use the record. Only developers of the managed package can modify the protected record and they can only do this with a package upgrade

Your final records could look something like this;


Now you have created your Custom Metadata Types, including configurations for the 4 different regions and can now access these configurations in APEX. 


APEX Access


Unfortunately APEX access is as of this writing Read-Only. But despite this fact, Custom Metadata Types are already incredible powerful. Here is how we would get out Email Editor Configuration Data and use it to customise our email editor look and feel;

 List<Email_Editor_Configuration__mdt> configuration = [  
    SELECT   
      Allow_Attachments__c, Allow_Document_Upload__c, Allow_Template_Use__c,   
      Default_Email_Folder__c, Editor_Height__c, Editor_Width__c, Region__c,   
      Save_As_Activity__c   
    FROM Focus_Product_Setting__mdt  
 ];  

Notice the "__mdt" ending for metadata type just we have "__c" for custom and "__r" for relationship.

Limitations


=> Number of fields that can be created for a custom meta data type definition are limited. See the following link for custom field types that are supported by custom metadata types Help & Training - Custom Metadata Types

= > Custom metadata types are still read-only as of this writing. Please vote here so we can see a change in this fast - Ability to update Metadata from Apex (Apex Metadata API)

Conclusion


Custom metadata types to me are pure magic because they can save us tons of hours and effort when building large customisable blocks of enterprise software or apps. I hope I was able to wet your appetite a little. I encourage you to take a look at Custom Metadata types. When you actually get to use them in real world projects, you will be blown away, positively of course. This I assure you.

For more on Custom Metadata Types go to Custom Metadata Types (CustomObject).

Please do not be shy to leave a comment. I appreciate your feedback, hints and critique.

The Fixer



5 comments:


  1. Thanks, this is generally helpful.
    Still, I followed step-by-step your method in this salesforce cpq online training
    salesforce cpq online training India

    ReplyDelete


  2. Techforce services is a Salesforce Consulting Services in Australia Specialising in delivering end to end Salesforce solutions ,Consulting, Implementation DevOps partners in australia We deliver applications and services more rapidly and reliably, but it’s more than a methodology – it cuts to the very core.Salesforce Data Analytics let us help you become a data driven organisation and ensure your data is working hard for your business This includes implementi
    Salesforce consulting companies
    Salesforce Services
    Staff augmentation companies
    Salesforce integration companies
    Salesforce Implementation services
    Salesforce DevOps partners
    Salesforce DevOps
    Managed project services

    ReplyDelete
  3. Spark primary development focus is on ease of development and integration with existing systems. Our secondary focus is on performance, though we also strive to maintain a high level of fault tolerance.

    ReplyDelete