27

Another good way to avoid recursion is highlighted in Chapter 6 of Dan Applemans's excellent book, Advanced Apex Programming. This particular example is around recursion when looking for a specific field change which is very common in many triggers. As mentioned in @BarCotters answer, you generally run your trigger on very specific criteria. A change in a ...


8

The difference is that you never set runCount, so it remains null each time it's called. Try this: public class checkRecursive { public static integer runCount; public static integer getRunCount() { if (runCount == null) { return runCount = 0; // Assigns 0 to runCount, and returns 0. } else { return ++...


6

There is no correct answer to this question as it's always going to depend on what triggers and workflows are configured in a given org. Like you say, updating the records being processed in an update trigger is likely to set off a waterfall, but so is insert in an insert, inserting in an update when there's an insert trigger etc., the number of scenarios ...


6

The code/transaction run by a Platform Event Trigger is run as the "Automated Process" User, and won't show up in logs unless you specifically set up a debug log for the "Automated Process" traced entity type.


5

Your trigger should only be firing on very specific criteria. Make them as specific as possible by comparing old and new field values to make sure your criteria is met. For example if you wanted to only fire when a contacts BirthDate changed then you could do the following: trigger ContactBeforeTrigger on Contact (before insert, before update, before ...


5

My guess is that you have a work flow rule that has a field update on the Unit_Placements_Sales__c object that is causing the trigger to fire a second time. A common way to prevent this problem is to use a Static variable. You need to use class to do this. This is an example of of how a static variable with prevent the recursion. Utility Class public ...


5

this is a great question. We had similar issues for years. First of all the Recursive class is a great way to make sure that a trigger is executed once. In your case the complexity has been increased by adding a workflow update. As described in the salesforce documentation "Triggers and Order of Execution" Workflow-Field-Updates can fire triggers again. ...


5

First of all, using a simple Boolean variable for recursion control is a flawed approach if you ever will update in a transaction more than 200 records (like in some controller/REST service/execute anonymous/platform event trigger). A better solution involves managing a set of IDs and checking to see if the ID has been 'visited' before to see if you should ...


5

So as @cropredy suggested using static map instead this is what I tried. I used static set to solve this issue. I can't say this is the best solution or not but this is working. may me some usecases will be there please feel free to comment on this post. So I used set of Id static variable. Trigger trigger RN_Account on Account (after update) { ...


5

First of all, your if statement is incorrect: using OR means that this branch will always execute. For example, if RFP Response Status is "Out of business", then it will not be "Bad Number". You need to use && (and) instead of || (or). if(opp.RFP_Response_Status__c != 'Out of Business' && opp.RFP_Response_Status__c != 'Do NOT Call' ...


5

I created a similar data structure. It's basically just missing the lookup from friend to person. Also for the sake of simplicity, I'm using the name as an identifier, but it would be the same principle to use the person id instead. The data I used to recreate the graph in you example: Person__c:{Name=Lisa, Id=a0d9000000OJ2v7AAD} Person__c:{Name=Jane, Id=...


5

Using boolean flags is often something of a bodge. As well as stopping the undesired unlimited recursion, it can stop the logic from settling to the correct values. Best to first think through the sequence of inserts and updates and aim to eliminate the recursive cases. A simple cause of the recursion limit problem is updating the object - making a DML ...


4

The simple solution is to follow the Apex Developer Guide recommendations on Triggers. Field updates belong in a before trigger and do not require a separate update call. When applying field updates in this way, you do not even need a static flag to block recursion, because you will not cause update trigger re-entry. There are two types of triggers: ...


4

In The documentation of Trigger Order of Execution (link) we can see in the bottom Trigger.old contains a version of the objects before the specific update that fired the trigger. However, there is an exception. When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger won’t contain the ...


4

You can only enqueue one job from a job (be it Batchable or Queueable). There are pretty much exactly two reasons you would run into this error. Either XFTY_DummySObjectSupplier kicks off a Queueable, or the object you are creating data for has triggers which do the same. Regardless of which is the cause, you are going to hit a roadblock in that you can ...


3

Lacey's answer is correct, by applying a trigger framework to you system will resolve your issue and increase the maintainability. However, if you are not so committed to switch to a different design and simply want to resolve your issue, here is the sample code: public Class checkRecursive{ private static boolean runATrigger = true; private static ...


3

Those triggers are executing in the same context, so yes, the static variables are shared and the first trigger will prevent the second. You could either use multiple variables for more fine grained control, or switch to using one of the many trigger frameworks that are knocking about. The Enterprise Patterns are also a good way to go for managing triggers ...


3

First of all you have to make sure that your trigger is executed just one time. For doing this, you have to make one class and add static boolean variable with default value true in it. In the trigger, before executing your code keep a check that the variable is true or not. Once you check make the variable false. Following is the code for that. Class ...


3

After going over this question rather thoroughly, I think I came up with a utility that should do the trick. It's basically what @greenstork suggested, just implemented a little differently. Below is the utility code along with implementation close to the original example: public with sharing class BucketingUtility { public interface ...


3

Instead of populating oldIsWonMap in your method1, abstract out that logic into a separate method called populateIsWonMap and then within your processing methods, just call your method at the top top: populateIsWonMap(newMap, oldMap); //continue with your logic here Since the map is declared outside of your methods, it can be used by each method and held ...


3

Easiest way I can think of to do what your are trying to would be as follows: Keep in mind you may have to modify this a bit as I am not entirely clear on what you are trying to accomplish (If it is all records or a single record) Create a Date/Time field on the object / Custom setting When an event happens that needs to be processed check the time/date ...


3

If you are not going to go with a full-blown trigger framework (these frameworks often handle recursion), then you can go with something like my TriggerControl object. It uses the static variable concept, but is able to keep track of this per sObject which is good if you are dealing with a complex set of triggers interacting with each other. Try this: ...


3

As an addendum to @adrianLarson comment: Cross-object formula fields may be available in the before trigger context if the parent relationship is based on a required field or on a lookup field with non-null value. Looking at the Trigger Order of Execution 1 On the server, Salesforce: Loads the original record from the database or initializes the ...


3

You can not create a new SObject record within a before insert/update trigger of the same SObject type. You are just creating a infinite, recursive loop. Here is what is happening: insert or update is called on a new Lead AdobeToLead trigger is fired BEFORE that record is saved to the database AdobeToLead calls AdobeToLead.leadFunctionalities (side note, ...


3

The general rule of thumb is that if you can't have duplicates, don't use a Set. The correct form in your case would be to use a List, instead: list<Id> customObjIds = new list<Id>(); for(customObj c: trigger.new){ if(c.recordtypeId == 'x' && ((StatusOldValue != StatusNewValue) && Status ='Submitted'){ customObjIds.add(c.ID);}//...


3

Your trigger is creating a second record rather than updating the first record. You'd want to change your code as follows: trigger HandleTrigger on Input__c (before insert) { for(Input__c record: Trigger.new) { record.YourEmail__c = 'tringtrigger@gmail.com'; } } Recursion blocking is not necessary in this case.


3

If you want to avoid recursion the set of ids is the right way. Before anything else, filter the chuck of records by their id and keep only the ones not present in the set or that do not have an id yet. Update the set of ids. Do anything you have to do in your before trigger. If your trigger handles also inserts, update again the set of ids Do anything you ...


2

Keeping a list of the last value seen by the trigger as described by Chris Duncombe is not quite sufficient. In addition to the documented case of a workflow field update causing a trigger to be fired a second time with the same old/new versions of a record, there are a couple other cases you may need to handle. Update events firing before insert events ...


2

I remember this problem distinctly especially with RSF and formulas based on RSF fields. Here is a simple use case Parent Obj P contains RSF on Child object C. Parent object may also have formulas based on the value of the RSF Triggers exist on both Child C and Parent C DML occurs on child C. C's trigger does DML upon parent P Parent P triggers fires, code ...


2

I had a situation recently where adding a simple workflow item (set a field under certain conditions) interfered somehow with triggers. I've got several levels of objects and trigger activity going on in too many of them. Turning off that one workflow got the triggers working again.


Only top voted, non community-wiki answers of a minimum length are eligible