Any DML execution in SFDC is always split up into chunks of 200. Each chunk is then processed separately by code.
However, that is not related to governor limits. Governor Limits are applied against a complete transaction. A transaction can contain multiple insert, updates, deletes, etc. All the stuff you do in the transaction is added together to measure up against the Governor Limits.
So whether or not you will hit governor limits when updating 4000 records at once depends on what other actions are in your transaction and on what other actions are triggered by your update.
E.g. just updating 4000 records without hitting any other workflow and/or triggers will not be a problem.
As I have just rewritten our internal unit test design patterns I've tested this quiet thoroughly and believe I have a proper grasp on how @testSetup
currently handles governing limits within the test class
In short, any DML statement within the context of @testSetup
will not count against your overall test class limits but SOQL statements will.
For example:
@testSetup public static void virtualSandbox(){
Account[] accts = new List<Account>();
for(Integer i=0;i<3;i++) {
Account a = new Account(Name='Acme' + i,BillingCity='San Francisco');
accts.add(a);
}
INSERT accts;
System.debug('Total Number of SOQL Queries allowed in this apex code context: ' + Limits.getQueries());
List<Account> account_test = [SELECT Id, Name, QB_Company_File__c FROM Account];
System.debug('Total Number of SOQL Queries allowed in this apex code context: ' + Limits.getQueries());
}
The above INSERT
on Accounts will have no influence on your governing limit in of itself but the SOQL statement will count as 1.
NOTE: If your org has events that are triggered from that INSERT
(which you likely do), THEN any DML or SOQL statement that proceeds from those are considered outside the context of @testSetup
and will impact your overall governing limits for your test class.
As always these limits are reset within any test method when you invoke Test.startTest();
and Test.stopTest();
but this could affect how much data you can setup within your data setup method (for example when cascading dependencies like Contacts, which need Accounts).
Workflow Rules (WFR):
If you have a WFR on Leads that will INSERT an Activity based on certain criteria, then the INSERT of that Activity will not affect your limits but again if it triggers any DML/SOQL then expect it to impacting your limits
Workaround:
Because I have foundation test classes that cover a majority of the essential trigger context for every object I wanted to include as much data as necessary for certain test classes, but unfortunately I would run into limit issues quickly because of triggers. So thankfully, since we use Kevin O'Hara's TriggerHandler Framework, we were able to implement his handy bypass()
method which temporarily pauses all trigger activity within your TriggerHandler class
For example:
@testSetup public static void virtualSandbox(){
TriggerHandler.bypass('AccountTriggerHandler'); // This will ignore the AccountTriggerHandler.cls that extends the TriggerHandler.cls framework
Account[] accts = new List<Account>();
for(Integer i=0;i<3;i++) {
Account a = new Account(Name='Acme' + i,BillingCity='San Francisco');
accts.add(a);
}
INSERT accts;
TriggerHandler.clearBypass('AccountTriggerHandler'); // This will turn it back on as needed for the remainder of the test.
}
Hope this proves to be useful in someone, feel free to comment with any adjustments you believe are necessary to this explanation.
Best Answer
Get Record
component in flow then it'd be a query.before update
andafter update
triggers one more time which is why you can confirm it's simply re-triggering the same batch of records again into the trigger.Deeper dive on the answers above:
It's stated in the Process Limits Documentation that flow actions count when you expect them to (queries and updates). If you think about it, PB is just really executing apex in the back-end with an easier to use UI.
Looking then at the Triggers and Order of Execution Doc, it covers all the various automation you mention that will count towards this.
Flows even have their own documentation concerning worrying about the limits they may hit in their Per-Transaction Flow Limits Doc and an article on Flow Bulkification in Transactions
Workflow rules, I believe, are bulkified in that they execute the workflow rules on the batch of records.
All documentation related to limits concern per-transaction (emails do have daily limits)