Custom Metadata Type Switches for Bypassing Record Trigger Flows

Often when I teach Apex and Flow triggers I get a common discussion in the classes. They are usually something like this: “My triggers work great until we have to load data.” Salesforce users often face challenges when importing large datasets into their Salesforce orgs. Apex and Flow triggers are fired during the data loading process Even though your triggers are properly bulkified you could start running into governor limit exceeded issues.

I’ve heard many stories on how admins and developers would try to solve this problem by inactivating the triggers. Unfortunately this is a very manual and error prone activity.

A simpler approach is to define a Custom Metadata Types as a trigger switch and build bypass logic into all of your triggers. In this article I will discuss bypass logic for record trigger flows. I will also show how. we can use an invocable apex call to simplify out bypass logic in a record flow trigger.

To give some historical perspective on this technique, when I worked in the financial industry many years ago working with batch Cobol, all of our code included bypass logic to use if there was a problem record as input.

Custom metadata types are a powerful feature that allows you to create customized setup objects where the records are treated as metadata instead of regular data. This is particularly useful when you need to migrate application configurations between different environments or package and install them. By leveraging custom metadata types, you can build declarative developer frameworks for internal teams, partners, and customers, enabling them to define and drive their own types of metadata-driven applications.

Metadata, in this context, refers to the information that describes the configuration of each customer's organization. Within a record trigger flow, you can query a custom metadata type using a Get Element operation. However, it's important to note that this currently counts against the limits of SOQL (Salesforce Object Query Language).

To address the SOQL Limit issue, the Salesforce Flow product team is actively working on a solution. In the meantime, an alternative approach is to utilize an Apex call to query a custom metadata type without impacting the SOQL limits. This allows you to perform the necessary operations while ensuring the efficient usage of resources.

The first demo will present the following:

1. A custom metadata type to enable/disable a trigger
2. A subflow that reads the custom metadata type record and returns enabled/disabled information
3. A record trigger flow that calls the subflow for bypass information

The second demo will present the following:

1. An invocable apex class that returns enabled/disabled information
2. A record trigger flow that calls the invokable apex class for bypass information

The approach will be to create a custom metadata type called Trigger Configuration (Trigger_Configuration__mdt). This will have a field for the trigger name, bypass user, and a check box field to indicate if the trigger is enabled.?

Next I created a record of data to to allow bypass logic in a record trigger flow called: New_Account_Default_Opportunity. Bypass User contains the username of the running user that can potentially bypass the execution of the trigger.

Next I wrote a subflow called Bypass Switch Subflow that uses a Get Element to query Trigger_Configuration__mdt for the appropriate record based on a user name and the trigger name. The Get returns the Is_Trigger_Enabled__c value. the subflow returns a true/false based on the state of Is_Trigger_Enabled__c. Note that the subflow is an Autolaunched flow.

For the demonstration I wrote a simple record trigger flow that will create a default opportunity every time a new account is created. This is Create, Action and Related Records trigger flow. The other type of flow is a Fast Field update. (As a side note, we have been referring to Fast Field update (FF) as french fries and Action and Related Records (ARR) as pirates because those terms are simpler to say and they are fun.) WE can only call subflows and invocable apex from pirates, not french fries. If you need to bypass a french fry you must add the bypass logic directly into your flow.

Calling the subflow requires us to provide the name of the trigger as defined in the custom metadata record. I use the global variable $User to provide the current running user’s username. isEnabled is a boolean value to hold the true/false value returned from the subflow.

Adding the subflow element and the decision element to all of your pirate record trigger flows allows you to have the option of bypassing the triggers without out having to deactivate the triggers.

One of the caveats of using a Get Element to query Trigger_Configuration__mdt is that the call goes against your SOQL governor limits at this time. If this is a concern then we can create an invokable apex class with invokable variables. In this apex class we can we can use custom metadata type methods to read our record data without the call going against the SOQL governor limits. In the apex class we call the public CustomMetadataType__mdt getInstance(String developerName) to return a CustomMetadataType__mdt record.

Here is an example of the apex class:

The import items to note:

• @InvocableMethod(label='Get Trigger Bypass Switch' description='Returns True/False bypass switch' category='Switch')
• Allows the apex class to be accessable from flow
• Trigger_Configuration__mdt varMySwitch = Trigger_Configuration__mdt.getInstance(input.triggerName);
• The custom metadata type method call to get our record
• global class FlowInput
• contains the @InvocableVariables that are exposed in the flow

The change to our flow is very simple:

Calling the Apex Action is very similar to calling the subflow:

Whether you choose to use the Get Element operation in a subflow or call an invocable Apex class with custom metadata type methods, you have the power to overcome the challenges of bypassing a trigger during a data load. Salesforce administrators and developers can harness the flexibility and customization offered by Custom Metadata Types, subflows, and invocable Apex classes to streamline trigger execution and ensure a smooth data loading experience.