Leveraging the flexibility of custom metadata types

Hello everyone, today I’d like to share how I’ve been leveraging custom metadata types in my Apex implementations and how it’s been improving my projects lately. Join to learn about Apex Design Patterns – Leveraging the flexibility of custom metadata types.

We all know that no matter how well-planned and executed a project is, there will always be changes that will need to be addressed after the code has been completed. Depending on how your code is implemented and how complex is your application development cycle, those changes can take minutes or days. This is when custom metadata types come in handy, and changes can be made on the fly, which might not even need to be deployed across different environments.

Apex triggers

Whether you’re working on a simple or complex project, chances are that there’ll be a requirement that will leverage an Apex trigger. It’s also not uncommon that the requirements related to a trigger are quite dynamic i.e. subject to change in unexpected ways due to changes within the business. We can prepare our trigger for those changes if we use custom metadata types.

Let’s jump right into an example. Imagine that we want to create a follow-up Task for every Opportunity inserted in our Org that is in the Qualification Stage and has its Amount greater than 10k. We can achieve this with the simple following code:

OpportunityTrigger.trigger

trigger OpportunityTrigger on Opportunity (after insert) {
    OpportunityTriggerHelper.createTask(Trigger.new);
}

OpportunityTriggerHelper.cls

public with sharing class OpportunityTriggerHelper {

    public static void createTask(List<Opportunity> opportunities) {
        List<Task> tasksToInsert = new List<Task>();
        for (Opportunity opportunity : opportunities) {
            if (opportunity.StageName == 'Qualification' && opportunity.Amount >= 10000) {
                Task task = new Task();
                task.Subject = 'Email';
                task.Description = 'Please follow-up with this Opportunity ASAP';
                task.WhatId = opportunity.Id;
                tasksToInsert.add(task);
            }
        }

        if (tasksToInsert.size() > 0) {
            insert tasksToInsert;
        }
    }
}

Now let’s take a step back and analyze this code. In terms of best practices we’re doing quite well since

1. we’re bullying our code, which means that if we are inserting more than one Opportunity record at a time we should still stay within Salesforce’s limits,
2. we’re also not including SOQL queries nor DML statements inside FOR loops, and
3. we’re not including business logic directly inside the trigger file which makes future changes in the Opportunity trigger easier.

So, what’s the problem here? Well, in real-world projects with tight timelines, undecided clients, and ever-changing business requirements, changing the logic of a trigger, especially if the code’s already been deployed into production, can take days or even weeks depending on the complexity of the project development pipeline. How can we prepare our code for last-minute changes from the business?

Custom metadata types to the rescue

This is the moment where custom metadata types fit like a glove into our code. If you are working in a fast-paced project for a complex organization, and have seen requirements changing in unexpected ways before, or have a feeling that they might change soon in the future, I’d say that it’s worth putting a little additional effort implementing a small framework up-front that will make our code logic easier to adjust or extend later if needed. Let’s see how it would work.

For this example, we would need at least two new custom metadata types:

Trigger_Entry_Criteria_Set__mdt

The first custom metadata type that we need is a group of criteria, something that we’ll call as Trigger Entry Criteria Set. This type will simply work as a container for multiple criteria that are related to a particular trigger. For our example, it will have only two fields – a checkbox to populate the criteria set as active or not, and a text field that will be used as a reference for our helper class.

Trigger_Entry_Criterion__mdt

The second type that we will use in our example is the Trigger Entry Criterion. This type represents an individual criterion that is related to a specific criteria set. Its fields are an active flag, a comparison picklist which represents the operation related to a specific criterion (e.g. equals to, populated, greater than, etc.), the name and the value of the field related to the record that is being evaluated, and a lookup to a Trigger Entry Criteria Set record.

Custom Metadata Records

Having created the custom metadata types, we can start to insert some records in our example. To meet our defined requirements, we need one criteria set record, which will be called Qualified Opportunities, and two criterion records – one to match the Opportunity Stage, and another to match its Amount field. Let’s take a look at our new code for the trigger.

CriterionEvaluator.cls

public interface CriterionEvaluator {

    public Boolean evaluateCriterion(String fieldName, String fieldValue, SObject record);
}

The first new file that we will add to our code will be the CriterionEvaluator interface. This interface will be the base type for all comparison operators that we might want to use in our framework (e.g. equals to, greater than etc.). It has a single Boolean method to evaluate a particular criterion given a field name, field value, and a record to be evaluated.

EqualsCriterionEvaluator.cls

public with sharing class EqualsCriterionEvaluator implements CriterionEvaluator {

    public override Boolean evaluateCriterion(String fieldName, String fieldValue, SObject record) {
        String actualFieldValue = String.valueOf(record.get(fieldName));
        return actualFieldValue == fieldValue;
    }
}

We then have our first comparison operator for the Equals To comparison. It simply implements the evaluateCriterion method by retrieving the actual field value and comparing it with the expected field value defined in our custom metadata record.

GreaterThanEqualToCriterionEvaluator.cls

public with sharing class GreaterThanEqualToCriterionEvaluator implements CriterionEvaluator {

    public override Boolean evaluateCriterion(String fieldName, String fieldValue, SObject record) {
        String actualFieldValue = String.valueOf(record.get(fieldName));
        return Decimal.valueOf(actualFieldValue) >= Decimal.valueOf(fieldValue);
}

Our second comparison operator has a similar idea to the previous one. We retrieve the actual field value and then compare it with the expected field value. The only caveat is to properly cast the fields to the Decimal class before comparing them.

TriggerEntryCriteriaHelper.cls

public without sharing class TriggerEntryCriteriaHelper {
    private static Map<String, CriterionEvaluator> criterionEvaluatorImplementationByComparison = new Map<String, CriterionEvaluator> {
            'Equals' => new EqualsCriterionEvaluator(),
            'Greater than/Equal to' => new GreaterThanEqualToCriterionEvaluator(),
};

    public static Boolean meetRequirements(SObject record, String className) {
        Trigger_Entry_Criteria_Set__mdt criteriaSet = getEntryCriteriaSet(className);
        for (Trigger_Entry_Criterion__mdt criterion : criteriaSet.Trigger_Entry_Criteria__r) {
            CriterionEvaluator criterionEvaluator = criterionEvaluatorImplementationByComparison.get(criterion.Comparison__c);
            if (criterionEvaluator.evaluateCriterion(criterion.Field_Name__c, criterion.Field_Value__c, record) == false) {
                return false;
            }
        }

        return true;
    }

    private static Trigger_Entry_Criteria_Set__mdt getEntryCriteriaSet(String className) {
        return [
                SELECT Id,
                (
                        SELECT  Id,
                                Comparison__c,
                                Field_Name__c,
                                Field_Value__c
                        FROM Trigger_Entry_Criteria__r
                        WHERE Active__c = TRUE
                )
                FROM Trigger_Entry_Criteria_Set__mdt
                WHERE Helper_Class__c = :className
                AND Active__c = TRUE
        ];
    }
}

Next is TriggerEntryCriteriaHelper, the main class of our framework. This class has a Map with each one of our comparison evaluator types that can be easily extended if needed, one public method that decides if a particular record meets the requirements specified in the custom metadata, and an auxiliary method with a SOQL query to retrieve a Trigger Entry Criteria Set record and its related criterion records.

The meetRequirements method is straightforward – it retrieves the criteria records related to a given helper class, iterates over them returning false if at least one doesn’t pass, and then returns true otherwise i.e. all criteria are successfully satisfied.

Finally, we have a new version of our main trigger class:

OpportunityTriggerHelper.cls

public with sharing class OpportunityTriggerHelper {

    public static void createTask(List<Opportunity> opportunities) {
        List<Task> tasksToInsert = new List<Task>();
        for (Opportunity opportunity : opportunities) {
            if (TriggerEntryCriteriaHelper.meetRequirements(opportunity, 'QualifiedOpportunitiesHelper')) {
                Task task = new Task();
                task.Subject = 'Email';
                task.Description = 'Please follow-up with this Opportunity ASAP';
                task.WhatId = opportunity.Id;
                tasksToInsert.add(task);
            }
        }

        if (tasksToInsert.size() > 0) {
            insert tasksToInsert;
        }
    }
}

The only difference is the if statement, we’re not hard-coding it anymore but calling the TriggerEntryCriteriaHelper class passing the Opportunity record to be evaluated as well as the helper class name so we can fetch the related custom metadata records.

Summary

The main advantage of this alternate approach is that our trigger is now ready to accommodate any changes in its entry criteria since it’s all being driven by custom metadata. This means that the criteria can be changed by Salesforce Admins directly in the Production Org without the need of changing the code and then going through the whole application development cycle.

And that’s about it! Please let me know your thoughts about this framework in the comments. If you think that this type of content is useful and you’d like to see more of it, please like and share this post. As always, stay tuned for more Salesforce content! I hope Leveraging the flexibility of custom metadata types posts will help you.