+ Start a Discussion
frasuyetfrasuyet 

Trigger Needs to Fire Once - What is Best Approach?

What is the best approach for a trigger to only fire once, after my IF condition has been met? The code below operates as it should once the IF condition is met - case is created.
 
However, the account could remain in the IF condition state for a couple of days. In the mean time, a simple update to the account could occur (e.g. phone number update) which would fire the trigger (again) thus a second (duplicate) case is created - not so good.
 
Where does my code need to be modified to prevent this behavior? I only need to have the trigger fire once when the original IF statement criteria is met. Of course, if the account falls out of the IF statment condition and then back in, the trigger would fire again - that's expected behavior.

 

Thanks.

 

 

trigger CreateVenereRequestIdCase on Account (before update) {

Case[] newCase = new Case[0];
for (Account a : Trigger.new) {
Account beforeUpdate = System.Trigger.oldMap.get(a.Id);
if((a.RecordTypeId == '012700000009Tor' || a.RecordTypeId == '012700000009JNI')
&& a.Venere_Module_ID__c == null && a.Venere_ID__c == null && a.Request_Venere_ID__c == TRUE && beforeUpdate.Request_Venere_ID__c == FALSE)
system.debug('Here is the account id: ' + a.Id);
newCase.add(new Case(
accountID = a.id,
Origin = 'Market Manager',
Priority = 'Medium',
RecordTypeID = '012T00000000Obu', //HDM - Venere Request ID
Status = 'New',
Subject = 'Venere ID Request',
Description = 'Please create a new Venere ID for ' + a.Name)
);

}
insert newCase;

}

 


 

 

 

 

 

Best Answer chosen by Admin (Salesforce Developers) 
jbroquistjbroquist
Wrote up a blog post showing how you could use my approach ...

All Answers

TehNrdTehNrd

Easiest way is to create a checkbox field on the account to see if case has been created, if false: update this field to true and insert case, if true, do nothing.

 

See code below:

 

 

trigger CreateVenereRequestIdCase on Account (before update) { Case[] newCase = new Case[0]; for (Account a : Trigger.new) { Account beforeUpdate = System.Trigger.oldMap.get(a.Id); if(a.Has_Case_Been_Created__c == false && (a.RecordTypeId == '012700000009Tor' || a.RecordTypeId == '012700000009JNI') && a.Venere_Module_ID__c == null && a.Venere_ID__c == null && a.Request_Venere_ID__c == TRUE && beforeUpdate.Request_Venere_ID__c == FALSE) system.debug('Here is the account id: ' + a.Id); a.Has_Case_Been_Created__c = true; newCase.add(new Case( accountID = a.id, Origin = 'Market Manager', Priority = 'Medium', RecordTypeID = '012T00000000Obu', //HDM - Venere Request ID Status = 'New', Subject = 'Venere ID Request', Description = 'Please create a new Venere ID for ' + a.Name) ); } if(newCase.size() > 0){ insert newCase; } }

-Jason

 

jbroquistjbroquist

I would set my trigger up to compare the values of trigger.old with trigger.new to see if the values have changed, if they HAVE changed, I would then run the IF clause you already have in place. This will allow you to edit non-related fields like phone number in the interim time ...

 

Let me know if you need a further explanation ...

jbroquistjbroquist
What TehNrd said will work as well ... you will just need additional workflows/triggers to reset the checkbox if any of the values are changed ...
jhoskins_orljhoskins_orl

Instead of hard coding RecordType may I recommend:

 

something like...

 

    public static String getRTIDbyDevName(String DeveloperName){
        RecordType[] RTs = [select id from RecordType where DeveloperName = :DeveloperName Limit 1];
        if(RTs.size() == 1){
            return RTs[0].id;
        }
        return null;                 
    }
TehNrdTehNrd

But that name could still be changed by a rogue admin that is trying to keep Name and Label in sync. For managaged packages this must be done as the Id will always be unique. Yet for home grown code I know what the Id is and I know it is not going to change.

 

One SOQL query may not seem like much there there have been times where I need to remove queries because of limits and these type of queries are the first on the chopping block.

jhoskins_orljhoskins_orl

Agreed -

 

It depends on your environment. Our stuff is pretty well documented.

Our Admins have strict instructions not to change Unique IDs or API Names

 

We typically create RecordTypes in a dev org before moving to prod and when we push new RecordType from dev to prod it get another Id. This was my work around....

 

We're not using managed packages... :-(

jbroquistjbroquist
Wrote up a blog post showing how you could use my approach ...
This was selected as the best answer
frasuyetfrasuyet

@jbroquist - a very informative and helfpul blog post.

 

@TehNrd - your approach was similar to what I had previously thought of but knew there must be another way that didn't involve creating another custom field. That said, your approach is valid.

 

@jhoskins_orl - thanks for the heads up. I am still a dev neophyte so taking baby steps but will remember your record type recommendation for future dev work. 

 

Now, time to focus on code coverage and get it over the finish line. 

 

Thanks again!