Implementing Singleton Design Pattern in Apex – Use Case II

by Sudipta Deb | Jun 4, 2015 | 501, Apex, design pattern, dev 501, singleton, use case | 0 comments


This post is part of the series – Design Pattern in Apex
Today in this post I will explain how Singleton Design Pattern can be used to stop calling the same trigger twice.

Consider the situation – You as a developer, is updating a field in Trigger which in turns calls a workflow and in that workflow action you are again updating some other field from the same object. And to your surprise, the same trigger is getting triggered again. Getting confused, right?

Let’s become more specific with the situation.
Consider the below object – Airport__c

The requirements are –

  • Req 1: Send an email if the country and type of an airport changed.
  • Req 2: If the country of an airport changed to “India”, change the type to “International”. 
To achieve the above two requirements, we have implemented –
  • One trigger, which will send the email if the country and type of an airport changed.
  • One workflow, which will change the type to “International” (Workflow action) if the country of an airport changed to “India”.
Here is the trigger –

The trigger looks really simple. But you know what will happen, when you will change the country of an airport to “India”, you will get two emails. You know why?

First email you will get from Line#6. 
After that, workflow action will change the type of the airport to “International”. Due to this change you will get another email from Line#11.

To solve this we need to implement Singleton Design Patten as shown below –
StopRecursive – 


MyAirportTrigger –

With the above approach, as you can see we are checking for boolean value in the trigger(line# 4 & 10). If the value is false, then only we are sending the loop and at the same time changing the value to true. So the next time, in the same transaction, even if the trigger is getting called, it will not do any operation, because we have changed the boolean value to true.

I hope you have understood how singleton design pattern can be used to stop calling same trigger recursively. Please let me know your feedback. Thanks.

Written by

Related Posts

New Apex Method | Extracting Picklist Values Based on Record Type Inside Apex

New Apex Method | Extracting Picklist Values Based on Record Type Inside Apex

For years, Salesforce developers have faced a common challenge: programmatically retrieving picklist values that are specific to a certain Record Type directly within Apex. The “solutions” often involved either complex SOQL queries against metadata, relying on the UI API (with its associated callout limits and serialization overhead), or maintaining clunky custom metadata/settings.

Good news, Technical Potpourri readers! The Salesforce Spring ’26 release is bringing a game-changer that will significantly simplify your Apex code and improve performance: native Apex methods to filter picklist values by Record Type!

read more...
Apex Cursor and Its Advantages Over Batch Processing

Apex Cursor and Its Advantages Over Batch Processing

Struggling with large datasets and SOQL governor limits in Salesforce? In this video, I will dive deep into Apex Cursors, the powerful new feature that revolutionizes how we process millions of records.

Apex Cursors allow developers to navigate through query results in manageable chunks within a single transaction or across Queueable jobs. In this video, I will show you the correct way to implement Apex Cursor and also when this is an exception, how to handle that and perform retry.

read more...

0 Comments

Leave a Reply