Trigger Actions Framework

Administrators use platform products like Flow to deliver powerful business processes, and developers can write Apex to handle more complicated scenarios. The biggest question for Salesforce architects has been how to arrange these tools together to build complete solutions. In this post we will talk about how to orchestrate ALL of your Salesforce Automation with the Trigger Actions Framework.

Automation Choices can be Tricky…

It is a well documented best practice to pick one automation tool per sObject and stick with it. This is great in theory, but in practice it is rarely ever executed well. Many Salesforce orgs have a mixed solution of some logic in Apex triggers, some logic in Process Builder, and some logic in Flow for a given sObject. All of this automation can make maintaining and extending your Salesforce implementation very tricky and expensive in the long run. The Trigger Actions Framework offers a uniquely powerful way for developers and administrators to define and orchestrate automations on the Salesforce platform.

Partition your Logic and Control the Order

The Trigger Actions Framework framework allows developers to partition their trigger logic into small individual classes for each action they want to take, rather than combining all of those into one massive trigger handler class. After your action classes are written, use custom metadata to control the order of execution within a given context.

Trigger OpportunityTrigger on Opportunity (
  before insert, 
  after insert,
  before update,
  after update,
  before delete,
  after delete,
  after undelete
) {
   new MetadataTriggerHandler().run();
}

.

public class ta_Opportunity_StageInsertRules implements TriggerAction.BeforeInsert {
  @TestVisible
  private static final String PROSPECTING = 'Prospecting';
  @TestVisible

  private static final String INVALID_STAGE_INSERT_ERROR = 'The Stage must be \'Prospecting\'
when an Opportunity is created';
  public void beforeInsert(List<Opportunity> newList){
    for (Opportunity opp : newList) {
     if (opp.StageName != PROSPECTING) {
       opp.addError(INVALID_STAGE_INSERT_ERROR);
     }
    }
  }
}

Support for Flows

The Trigger Actions Framework can also allow you to invoke a Flow by name, and determine the order of the Flow’s execution amongst other trigger actions in a given trigger context. The framework has some features which allow you to check for a record’s previous value and apply your updates back to a record before insert/update. Here is an example of an auto-launched flow that checks if a records’ status has changed and if so, it sets the records description to a default value – all of this is done before update.

Here is an example of an auto-launched flow that checks if a records’ status has changed and if so, it sets the records description to a default value – all of this is done before update.

Flows are configured just like Apex triggered actions – just provide the API name of the Flow and the order in which you would like it to execute for the given context.

The Trigger Actions Framework can allow developers and administrators to create new features together while giving management and future team members a single view to understand all record automation on a given sObject. Be sure to check out the project on GitHub and share this with the developers, administrators, and architects in charge of your organization’s Salesforce implementation.

Trigger Actions Framework Video

YouTube video

Thanks Mitch Spano for writing a guest blog post and sharing with us.

Amit Chaudhary
Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates.

He is a active blogger and founder of Apex Hours.

Articles: 461

One comment

  1. Can MetadataTriggerHandler be updated to accept newMap and oldMap instead of newList and oldList Respectively?

Leave a Reply

Your email address will not be published. Required fields are marked *