Salesforce Trigger Driven Development
Update 2nd April 2017: this is an April Fool post, although if you have any examples of trigger driven development I’d still love to see them.
April 1, 2017 will go down in history as the day that Salesforce development was turned on it’s head to unleash the full capability of triggers on an unsuspecting development ecosystem.
Background
Over the last 12 months myself and a crack team of BrightGen developers have been working on ways to improve the performance of our applications. Up until recently we’ve been following the Salesforce best practice of putting as little code as possible inside triggers and instead delegating to external classes. Little did we know that this advice is nothing short of a conspiracy to slow applications down. After inadvertently merging in a 1,500 line trigger to our codebase, we saw an unexpected, and frankly staggering, increase in performance.
Trigger all the Things
A period of investigation and confirmation then followed, after which we were confident that the more code we could move into triggers the happier our users would be, we took a step back and tried to figure out how we could leverage this improved performance across all areas of functionality.
Rather than carrying out processing in a Visualforce controller method, for example selecting all the account records whose name contains a particular word:
public List<Account> getAccounts()
{
return [select, Id, Name from Account
where name like '%prank%'];
}We’d move this processing into a trigger and set the results into a static controller property. Obviously we don’t want the trigger doing this every time — this is about making things better after all — so we set another static property to tell the trigger what action we want it to take. In order to fire the trigger, we insert a fake account that gets deleted once the processing is complete. Our controller now has the following code:
public class MyController
{
public static String Operation;
public static List<Account> Results; public List<Account> getAccounts
{
Operation='Keir: Select accounts';
Account fakeAcc=new Account(Name='Fake');
insert acc;
delete acc; return Results;
}
}
and we have a trigger doing the heavy lifting:
trigger AccountUtils on Account (before insert)
{
if (MyController.Operation=='Keir: Select Accounts')
{
MyController.Results=[select, Id, Name from Account
where name like '%prank%'];
}
// if statements to handle other operations goes here
}This also demonstrates another benefit to trigger driven development — good looking code comes as standard. No more polluting your business logic with actual logic, simply set a few parameters, pull the pin on the trigger and your job is done. There’s a certain elegance and flow about this approach that makes it irresistible to hardcore developers.
Note that I have prefixed the operation with my first name — this allows each developer to define their own operations with the same name and be sure they aren’t treading on each others toes. If you want to understand more about the purpose of the operation, just ask all the developers with that first name if it was them. Collaboration FTW!
More Triggers = More Awesome
With trigger driven development you can forget about whether you should use one trigger per action and operation or one trigger for everything, and just write as many triggers as you want. Order of execution no longer applies because you have specified the operation that actually needs to take place prior to carrying out your DML. Thus even if you end up with 200 triggers for the same object, the platform will eventually hit the one you want and carry out the processing you have requested. This ensures that each trigger focuses on it’s own area of responsibility — we’ve found that breaking it up by developer, much like the operations above, really helps with this. If you are a one-person development team though I wouldn’t advise it — in that case it’s better to split them out into the day of the week that you carried out the development.
This is the end of the Beginning
I’ve really only dipped a toe into Trigger Driven Development in this post, so there will be a lot more content to come in the future. This has generated real excitement at Salesforce and I’m working with the Trailhead team to put together a Trail to help everyone become a Trigger Driven Developer. It will take a while, as there’s a lot to cover, but we’re expecting to make it available in exactly 12 months.
Show us your Triggers
If you are as excited about the possibilities of Trigger Driven Development as we are, write a response with examples of your work. The best entries will receive a mention in my upcoming book “All About Doing Development with Triggers”, which is sure to be a best seller.
I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 6 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring the best people, but not to carry out Trigger Driven Development.
You can find my (usually) more technical thoughts at the Bob Buzzard Blog
