Apex Code Development You need to sign in to do that
Don't have an account?
frasuyet 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;
}
All Answers
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
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 ...
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;
}
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.
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... :-(
@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!