Can someone clarify when a Trigger executes on a single record vs. multiple in one context?Is there a simple...
Why Lie algebras if what we care about in physics are groups?
Calculating Fibonacci sequence in several different ways
Stellen - Putting, or putting away?
Is it ethical to tell my teaching assistant that I like him?
Found old paper shares of Motorola Inc that has since been broken up
Killing a star safely
Source for "everyone has a specific area of Torah that they're naturally drawn to"
Facebook video calling problem in Safari
Why is the UH-60 tail rotor canted?
How to handle not being able to attend as often as I'd like
Count the identical pairs in two lists
Create Circle with Inner Radius
As a DM of a 4-player group, would it be appropriate for me to run a private 1-on-1 session so that one PC can act secretly?
"It is what it is"
Would using carbon dioxide as fuel work to reduce the greenhouse effect?
What does a Nintendo Game Boy do when turned on without a game cartridge inserted?
What is the best word describing the nature of expiring in a short amount of time, connoting "losing public attention"?
Why is a PhD thesis typically 150 pages?
How should I handle a question regarding my regrets during an interview?
Is it OK to accept a job opportunity while planning on not taking it?
Storyboarding Approaches for the Non-Artistic
How do you structure large embedded projects?
Host telling me to cancel my booking in exchange for a discount?
Is it better to merge "often" or only after completion do a big merge of feature branches?
Can someone clarify when a Trigger executes on a single record vs. multiple in one context?
Is there a simple way to serialize execution of Batchable class?@future and triggersHow can I communicate a trigger exception to user in a bulk upsert for each record?How to detect the name or id of currently running batch job from trigger?Trigger Execution order/contextCalling executeBatch() method of two Batchable classes in execute method of a Schedule class, Will this hit governor limits?Trigger Using The Incorrect Account ID in Bulk UpdatesWhy is this ContentNote trigger receiving 1 record at a time even though multiple records are being inserted?Delete Records before UpdateCan a Change Event Trigger include the same record multiple times?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
This may be a silly question, but I've been surprised by Salesforce enough to potentially look foolish for confirmation! Apologies, the question itself was difficult to phrase.
Fundamentally, since a trigger can execute once and include multiple records, the structure of it includes a list of records triggering it (rather than one context being just for one record). One obvious example of this being the case (multiple records opposed to one) is a bulk update where, of course, it's many records in one update rather than individually.
What I'm wondering is if there are multiple records in one context just because records were updated close enough to each other, rather than in a "bulk" update, even if technically under different create/update calls.
For context, we have an integration that takes a large, bulk batch of records from our source system, and upserts to SFDC. The way our integration member explained the upsert is that, yes, it's a bulk batch, but technically each record is sent out individually (but, of course, this moves fast so they are all created virtually at the same time). I am wondering if this would mean each record has its own trigger execution (so the "list" is just one record") since it's not technically a batch, or if salesforce receives them quick enough and considers them all together (and putting them all in the same context)...(or if maybe it's just asynchronous but still considered "batch" by salesforce). Regardless...
I suppose the root of my question has to do with how Salesforce establishes if something is in bulk to include in one context for the trigger, vs.
an individual execution. Is it just within a small time frame, or exclusively "batch" updates?
Again, apologies if this question is silly or confusing. Trying to establish the nature of our use case and how our trigger is processing it.
apex trigger batch triggercontext executioncontext
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
|
show 1 more comment
This may be a silly question, but I've been surprised by Salesforce enough to potentially look foolish for confirmation! Apologies, the question itself was difficult to phrase.
Fundamentally, since a trigger can execute once and include multiple records, the structure of it includes a list of records triggering it (rather than one context being just for one record). One obvious example of this being the case (multiple records opposed to one) is a bulk update where, of course, it's many records in one update rather than individually.
What I'm wondering is if there are multiple records in one context just because records were updated close enough to each other, rather than in a "bulk" update, even if technically under different create/update calls.
For context, we have an integration that takes a large, bulk batch of records from our source system, and upserts to SFDC. The way our integration member explained the upsert is that, yes, it's a bulk batch, but technically each record is sent out individually (but, of course, this moves fast so they are all created virtually at the same time). I am wondering if this would mean each record has its own trigger execution (so the "list" is just one record") since it's not technically a batch, or if salesforce receives them quick enough and considers them all together (and putting them all in the same context)...(or if maybe it's just asynchronous but still considered "batch" by salesforce). Regardless...
I suppose the root of my question has to do with how Salesforce establishes if something is in bulk to include in one context for the trigger, vs.
an individual execution. Is it just within a small time frame, or exclusively "batch" updates?
Again, apologies if this question is silly or confusing. Trying to establish the nature of our use case and how our trigger is processing it.
apex trigger batch triggercontext executioncontext
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
4
If they're being sent as individual API calls, then they would each be in their own execution context. That would generally be considered a very poor design though - passing multiple records to the APIs for insert or update, to conserve API calls by using 1 call per 200 (or fewer) records rather than an API call per record is one of, if not the primary reason for making triggers bulkified.
– Thomas Taylor
9 hours ago
It's interesting to consider poor vs good design from two angles (the way I see it). Poor design in regards to API calls would be individual; poor design for a trigger would be bulk because you could reach your SOQL query limit so easily even if you only have one query. That's actually the root of a problem I'm trying to solve with an existing trigger I just encountered that's reaching its limit, and I'm trying to figure out if its due to a bulk job (it has 5 queries in it - that won't take long to break in bulk!!) I understand generally you shouldn't have queries in triggers, but "never"?
– Natalie Paige
8 hours ago
1
@NataliePaige You just have to query smartly. Your SOQL queries should be able to bring up all the records you would possibly need. Never SOQL query within a for loop and use Map<Id, My_Custom_SObject__c> liberally and you should be fine
– Brian Miller
8 hours ago
1
If a SOQL query is running more than once per trigger execution, the trigger is not properly bulkified. Getting close to the limit with well-written triggers usually means triggers cascading across several objects.
– Thomas Taylor
8 hours ago
1
This is a great conversation to prime my continued investigation to my issue. Thank you both!!
– Natalie Paige
8 hours ago
|
show 1 more comment
This may be a silly question, but I've been surprised by Salesforce enough to potentially look foolish for confirmation! Apologies, the question itself was difficult to phrase.
Fundamentally, since a trigger can execute once and include multiple records, the structure of it includes a list of records triggering it (rather than one context being just for one record). One obvious example of this being the case (multiple records opposed to one) is a bulk update where, of course, it's many records in one update rather than individually.
What I'm wondering is if there are multiple records in one context just because records were updated close enough to each other, rather than in a "bulk" update, even if technically under different create/update calls.
For context, we have an integration that takes a large, bulk batch of records from our source system, and upserts to SFDC. The way our integration member explained the upsert is that, yes, it's a bulk batch, but technically each record is sent out individually (but, of course, this moves fast so they are all created virtually at the same time). I am wondering if this would mean each record has its own trigger execution (so the "list" is just one record") since it's not technically a batch, or if salesforce receives them quick enough and considers them all together (and putting them all in the same context)...(or if maybe it's just asynchronous but still considered "batch" by salesforce). Regardless...
I suppose the root of my question has to do with how Salesforce establishes if something is in bulk to include in one context for the trigger, vs.
an individual execution. Is it just within a small time frame, or exclusively "batch" updates?
Again, apologies if this question is silly or confusing. Trying to establish the nature of our use case and how our trigger is processing it.
apex trigger batch triggercontext executioncontext
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
This may be a silly question, but I've been surprised by Salesforce enough to potentially look foolish for confirmation! Apologies, the question itself was difficult to phrase.
Fundamentally, since a trigger can execute once and include multiple records, the structure of it includes a list of records triggering it (rather than one context being just for one record). One obvious example of this being the case (multiple records opposed to one) is a bulk update where, of course, it's many records in one update rather than individually.
What I'm wondering is if there are multiple records in one context just because records were updated close enough to each other, rather than in a "bulk" update, even if technically under different create/update calls.
For context, we have an integration that takes a large, bulk batch of records from our source system, and upserts to SFDC. The way our integration member explained the upsert is that, yes, it's a bulk batch, but technically each record is sent out individually (but, of course, this moves fast so they are all created virtually at the same time). I am wondering if this would mean each record has its own trigger execution (so the "list" is just one record") since it's not technically a batch, or if salesforce receives them quick enough and considers them all together (and putting them all in the same context)...(or if maybe it's just asynchronous but still considered "batch" by salesforce). Regardless...
I suppose the root of my question has to do with how Salesforce establishes if something is in bulk to include in one context for the trigger, vs.
an individual execution. Is it just within a small time frame, or exclusively "batch" updates?
Again, apologies if this question is silly or confusing. Trying to establish the nature of our use case and how our trigger is processing it.
apex trigger batch triggercontext executioncontext
apex trigger batch triggercontext executioncontext
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
asked 9 hours ago
Natalie PaigeNatalie Paige
11510 bronze badges
11510 bronze badges
4
If they're being sent as individual API calls, then they would each be in their own execution context. That would generally be considered a very poor design though - passing multiple records to the APIs for insert or update, to conserve API calls by using 1 call per 200 (or fewer) records rather than an API call per record is one of, if not the primary reason for making triggers bulkified.
– Thomas Taylor
9 hours ago
It's interesting to consider poor vs good design from two angles (the way I see it). Poor design in regards to API calls would be individual; poor design for a trigger would be bulk because you could reach your SOQL query limit so easily even if you only have one query. That's actually the root of a problem I'm trying to solve with an existing trigger I just encountered that's reaching its limit, and I'm trying to figure out if its due to a bulk job (it has 5 queries in it - that won't take long to break in bulk!!) I understand generally you shouldn't have queries in triggers, but "never"?
– Natalie Paige
8 hours ago
1
@NataliePaige You just have to query smartly. Your SOQL queries should be able to bring up all the records you would possibly need. Never SOQL query within a for loop and use Map<Id, My_Custom_SObject__c> liberally and you should be fine
– Brian Miller
8 hours ago
1
If a SOQL query is running more than once per trigger execution, the trigger is not properly bulkified. Getting close to the limit with well-written triggers usually means triggers cascading across several objects.
– Thomas Taylor
8 hours ago
1
This is a great conversation to prime my continued investigation to my issue. Thank you both!!
– Natalie Paige
8 hours ago
|
show 1 more comment
4
If they're being sent as individual API calls, then they would each be in their own execution context. That would generally be considered a very poor design though - passing multiple records to the APIs for insert or update, to conserve API calls by using 1 call per 200 (or fewer) records rather than an API call per record is one of, if not the primary reason for making triggers bulkified.
– Thomas Taylor
9 hours ago
It's interesting to consider poor vs good design from two angles (the way I see it). Poor design in regards to API calls would be individual; poor design for a trigger would be bulk because you could reach your SOQL query limit so easily even if you only have one query. That's actually the root of a problem I'm trying to solve with an existing trigger I just encountered that's reaching its limit, and I'm trying to figure out if its due to a bulk job (it has 5 queries in it - that won't take long to break in bulk!!) I understand generally you shouldn't have queries in triggers, but "never"?
– Natalie Paige
8 hours ago
1
@NataliePaige You just have to query smartly. Your SOQL queries should be able to bring up all the records you would possibly need. Never SOQL query within a for loop and use Map<Id, My_Custom_SObject__c> liberally and you should be fine
– Brian Miller
8 hours ago
1
If a SOQL query is running more than once per trigger execution, the trigger is not properly bulkified. Getting close to the limit with well-written triggers usually means triggers cascading across several objects.
– Thomas Taylor
8 hours ago
1
This is a great conversation to prime my continued investigation to my issue. Thank you both!!
– Natalie Paige
8 hours ago
4
4
If they're being sent as individual API calls, then they would each be in their own execution context. That would generally be considered a very poor design though - passing multiple records to the APIs for insert or update, to conserve API calls by using 1 call per 200 (or fewer) records rather than an API call per record is one of, if not the primary reason for making triggers bulkified.
– Thomas Taylor
9 hours ago
If they're being sent as individual API calls, then they would each be in their own execution context. That would generally be considered a very poor design though - passing multiple records to the APIs for insert or update, to conserve API calls by using 1 call per 200 (or fewer) records rather than an API call per record is one of, if not the primary reason for making triggers bulkified.
– Thomas Taylor
9 hours ago
It's interesting to consider poor vs good design from two angles (the way I see it). Poor design in regards to API calls would be individual; poor design for a trigger would be bulk because you could reach your SOQL query limit so easily even if you only have one query. That's actually the root of a problem I'm trying to solve with an existing trigger I just encountered that's reaching its limit, and I'm trying to figure out if its due to a bulk job (it has 5 queries in it - that won't take long to break in bulk!!) I understand generally you shouldn't have queries in triggers, but "never"?
– Natalie Paige
8 hours ago
It's interesting to consider poor vs good design from two angles (the way I see it). Poor design in regards to API calls would be individual; poor design for a trigger would be bulk because you could reach your SOQL query limit so easily even if you only have one query. That's actually the root of a problem I'm trying to solve with an existing trigger I just encountered that's reaching its limit, and I'm trying to figure out if its due to a bulk job (it has 5 queries in it - that won't take long to break in bulk!!) I understand generally you shouldn't have queries in triggers, but "never"?
– Natalie Paige
8 hours ago
1
1
@NataliePaige You just have to query smartly. Your SOQL queries should be able to bring up all the records you would possibly need. Never SOQL query within a for loop and use Map<Id, My_Custom_SObject__c> liberally and you should be fine
– Brian Miller
8 hours ago
@NataliePaige You just have to query smartly. Your SOQL queries should be able to bring up all the records you would possibly need. Never SOQL query within a for loop and use Map<Id, My_Custom_SObject__c> liberally and you should be fine
– Brian Miller
8 hours ago
1
1
If a SOQL query is running more than once per trigger execution, the trigger is not properly bulkified. Getting close to the limit with well-written triggers usually means triggers cascading across several objects.
– Thomas Taylor
8 hours ago
If a SOQL query is running more than once per trigger execution, the trigger is not properly bulkified. Getting close to the limit with well-written triggers usually means triggers cascading across several objects.
– Thomas Taylor
8 hours ago
1
1
This is a great conversation to prime my continued investigation to my issue. Thank you both!!
– Natalie Paige
8 hours ago
This is a great conversation to prime my continued investigation to my issue. Thank you both!!
– Natalie Paige
8 hours ago
|
show 1 more comment
2 Answers
2
active
oldest
votes
If the external system is doing a simple REST API call into Salesforce (albeit many of them very quickly together, even in parallel), Salesforce will treat each call as a separate Transaction, and triggers will run on each item separately.
In general, multiple records are only processed together if a singular action was called on multiple records at once (like mass edit on a list view, uploads from a CSV, or custom VF / Aura / LWC components that intentionally call an insert/update on multiple SObject records at once).
There are a number of API protocols though that will ensure that bulk records will come into Salesforce, and thereby the trigger will handle them in bulk appropriately. See the Bulk API trailhead and REST API Composite documentation for some guidance.
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
add a comment |
In addition to @BrianMiller answer,
If one or more publishers publish Platform Event Foo__e as follows
- T(0) - publish 10
Foo__e
- T(1) - publish 3
Foo__e
- T(2) - publish 6
Foo__e
then the trigger that subscribes to Foo__e could see anywhere from:
1 to all 19 (and anything in between) Foo__e in a single transaction as SFDC Platform Event subscription code will "batch" Platform Events into a single transaction using rules that are opaque.
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
This is wonderful - I didn't know Platform Events operate in this fashion
– Brian Miller
8 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f270452%2fcan-someone-clarify-when-a-trigger-executes-on-a-single-record-vs-multiple-in-o%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If the external system is doing a simple REST API call into Salesforce (albeit many of them very quickly together, even in parallel), Salesforce will treat each call as a separate Transaction, and triggers will run on each item separately.
In general, multiple records are only processed together if a singular action was called on multiple records at once (like mass edit on a list view, uploads from a CSV, or custom VF / Aura / LWC components that intentionally call an insert/update on multiple SObject records at once).
There are a number of API protocols though that will ensure that bulk records will come into Salesforce, and thereby the trigger will handle them in bulk appropriately. See the Bulk API trailhead and REST API Composite documentation for some guidance.
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
add a comment |
If the external system is doing a simple REST API call into Salesforce (albeit many of them very quickly together, even in parallel), Salesforce will treat each call as a separate Transaction, and triggers will run on each item separately.
In general, multiple records are only processed together if a singular action was called on multiple records at once (like mass edit on a list view, uploads from a CSV, or custom VF / Aura / LWC components that intentionally call an insert/update on multiple SObject records at once).
There are a number of API protocols though that will ensure that bulk records will come into Salesforce, and thereby the trigger will handle them in bulk appropriately. See the Bulk API trailhead and REST API Composite documentation for some guidance.
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
add a comment |
If the external system is doing a simple REST API call into Salesforce (albeit many of them very quickly together, even in parallel), Salesforce will treat each call as a separate Transaction, and triggers will run on each item separately.
In general, multiple records are only processed together if a singular action was called on multiple records at once (like mass edit on a list view, uploads from a CSV, or custom VF / Aura / LWC components that intentionally call an insert/update on multiple SObject records at once).
There are a number of API protocols though that will ensure that bulk records will come into Salesforce, and thereby the trigger will handle them in bulk appropriately. See the Bulk API trailhead and REST API Composite documentation for some guidance.
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
If the external system is doing a simple REST API call into Salesforce (albeit many of them very quickly together, even in parallel), Salesforce will treat each call as a separate Transaction, and triggers will run on each item separately.
In general, multiple records are only processed together if a singular action was called on multiple records at once (like mass edit on a list view, uploads from a CSV, or custom VF / Aura / LWC components that intentionally call an insert/update on multiple SObject records at once).
There are a number of API protocols though that will ensure that bulk records will come into Salesforce, and thereby the trigger will handle them in bulk appropriately. See the Bulk API trailhead and REST API Composite documentation for some guidance.
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
answered 9 hours ago
Brian MillerBrian Miller
1,4465 silver badges21 bronze badges
1,4465 silver badges21 bronze badges
add a comment |
add a comment |
In addition to @BrianMiller answer,
If one or more publishers publish Platform Event Foo__e as follows
- T(0) - publish 10
Foo__e
- T(1) - publish 3
Foo__e
- T(2) - publish 6
Foo__e
then the trigger that subscribes to Foo__e could see anywhere from:
1 to all 19 (and anything in between) Foo__e in a single transaction as SFDC Platform Event subscription code will "batch" Platform Events into a single transaction using rules that are opaque.
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
This is wonderful - I didn't know Platform Events operate in this fashion
– Brian Miller
8 hours ago
add a comment |
In addition to @BrianMiller answer,
If one or more publishers publish Platform Event Foo__e as follows
- T(0) - publish 10
Foo__e
- T(1) - publish 3
Foo__e
- T(2) - publish 6
Foo__e
then the trigger that subscribes to Foo__e could see anywhere from:
1 to all 19 (and anything in between) Foo__e in a single transaction as SFDC Platform Event subscription code will "batch" Platform Events into a single transaction using rules that are opaque.
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
This is wonderful - I didn't know Platform Events operate in this fashion
– Brian Miller
8 hours ago
add a comment |
In addition to @BrianMiller answer,
If one or more publishers publish Platform Event Foo__e as follows
- T(0) - publish 10
Foo__e
- T(1) - publish 3
Foo__e
- T(2) - publish 6
Foo__e
then the trigger that subscribes to Foo__e could see anywhere from:
1 to all 19 (and anything in between) Foo__e in a single transaction as SFDC Platform Event subscription code will "batch" Platform Events into a single transaction using rules that are opaque.
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
In addition to @BrianMiller answer,
If one or more publishers publish Platform Event Foo__e as follows
- T(0) - publish 10
Foo__e
- T(1) - publish 3
Foo__e
- T(2) - publish 6
Foo__e
then the trigger that subscribes to Foo__e could see anywhere from:
1 to all 19 (and anything in between) Foo__e in a single transaction as SFDC Platform Event subscription code will "batch" Platform Events into a single transaction using rules that are opaque.
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
answered 8 hours ago
cropredycropredy
38.4k4 gold badges45 silver badges133 bronze badges
38.4k4 gold badges45 silver badges133 bronze badges
This is wonderful - I didn't know Platform Events operate in this fashion
– Brian Miller
8 hours ago
add a comment |
This is wonderful - I didn't know Platform Events operate in this fashion
– Brian Miller
8 hours ago
This is wonderful - I didn't know Platform Events operate in this fashion
– Brian Miller
8 hours ago
This is wonderful - I didn't know Platform Events operate in this fashion
– Brian Miller
8 hours ago
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f270452%2fcan-someone-clarify-when-a-trigger-executes-on-a-single-record-vs-multiple-in-o%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
If they're being sent as individual API calls, then they would each be in their own execution context. That would generally be considered a very poor design though - passing multiple records to the APIs for insert or update, to conserve API calls by using 1 call per 200 (or fewer) records rather than an API call per record is one of, if not the primary reason for making triggers bulkified.
– Thomas Taylor
9 hours ago
It's interesting to consider poor vs good design from two angles (the way I see it). Poor design in regards to API calls would be individual; poor design for a trigger would be bulk because you could reach your SOQL query limit so easily even if you only have one query. That's actually the root of a problem I'm trying to solve with an existing trigger I just encountered that's reaching its limit, and I'm trying to figure out if its due to a bulk job (it has 5 queries in it - that won't take long to break in bulk!!) I understand generally you shouldn't have queries in triggers, but "never"?
– Natalie Paige
8 hours ago
1
@NataliePaige You just have to query smartly. Your SOQL queries should be able to bring up all the records you would possibly need. Never SOQL query within a for loop and use Map<Id, My_Custom_SObject__c> liberally and you should be fine
– Brian Miller
8 hours ago
1
If a SOQL query is running more than once per trigger execution, the trigger is not properly bulkified. Getting close to the limit with well-written triggers usually means triggers cascading across several objects.
– Thomas Taylor
8 hours ago
1
This is a great conversation to prime my continued investigation to my issue. Thank you both!!
– Natalie Paige
8 hours ago