1

I have a scenario where I want to update the account from last modified contact. Suppose there is 1 account which has 402 contact record. The before insert trigger is running 3 times as the number of records are more than 200. How to know when all the records are inserted, then run my logic on them. I know I can use static list to capture all records but what will be the logic to know that all the records are inserted.

Trigger:

trigger DONOTDELETETriggerContact on Contact (before insert, before update, after insert, after update, after delete, after undelete) {

if(Trigger.isBefore && Trigger.isInsert){
    MyApexScenario.Scenario1(Trigger.new);
}

}

Class:

public static void Scenario1(List<Contact> conList){
    List<Contact> conUpdatedList = new List<Contact>();
    for(Contact conObj : conList){
        conUpdatedList.add(conObj);
    }
    if(!conUpdatedList.isEmpty()){
        system.debug('Total Records: '+conUpdatedList.size());
    }
}

Test Class:

`
    Test.starttest();
        Account acc = new Account();
        acc.name = 'test';
        insert acc;

        List<Contact> conList = new List<Contact>();
        for(Integer i = 1; i<=402; i++){
        contact con = new Contact();
        con.firstname = 'test';
        con.lastname = String.valueOf(i);
        con.accountid= acc.id;
        conList.add(con);
        }
        insert conList;
    Test.stoptest();`
4

Long story short, there is currently no good way for us to know when we're working on the final trigger chunk (I use "chunk" here to describe how Salesforce splits records undergoing DML into smaller sets of up to 200 records because "batch" is used elsewhere in Apex).

If you're willing to forego handling allOrNone = false transactions, it would be possible using a simple static integer and checking it against Limits.getDmlRows() (if you insert 402 records, checking that limit will return "402" even when you're running through the first trigger chunk). Having any other triggers run (or things like workflow field updates, after-save record triggered flows, and process builder) would complicate matters significantly.

The other consideration is that for you to take advantage of before triggers (and their ability to modify triggered records without the need for DML), you still need to run code for each trigger chunk.

The appropriate way to handle this situation is to be mindful of the number of queries you're running, and making sure your code is bulk friendly (no DML or Queries inside of loops, either directly or indirectly).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.