Mixing
Is there a benefit of using Process Builder vs Triggers
I went through a lot of different articles about Process Builder vs Triggers. Yet I can't say I clearly see the benefit of using Process Builder if you know how to write an apex trigger.
What would be a reason to go with Process Builder instead of a trigger? I understand that one doesn't need code coverage for process builder but I don't consider that a benefit.
I am also wondering if a lot of Process Builders add up over time if there's some sort of conflicts that they might impose on each other that becomes harder to debug?
apex process builder
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
asked Jan 15 at 17:47
ArthleteArthlete
919716
add a comment |
I went through a lot of different articles about Process Builder vs Triggers. Yet I can't say I clearly see the benefit of using Process Builder if you know how to write an apex trigger.
What would be a reason to go with Process Builder instead of a trigger? I understand that one doesn't need code coverage for process builder but I don't consider that a benefit.
I am also wondering if a lot of Process Builders add up over time if there's some sort of conflicts that they might impose on each other that becomes harder to debug?
apex process builder
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
asked Jan 15 at 17:47
ArthleteArthlete
919716
1
This is similar to salesforce.stackexchange.com/questions/139983/… (full disclosure: I wrote an answer on that question, and it's my highest-voted answer at this time)
– Derek F
Jan 15 at 19:04
@DerekF Thanks for linking to your answer! That was a good addition to what the others said.
– Arthlete
Jan 15 at 20:34
add a comment |
I went through a lot of different articles about Process Builder vs Triggers. Yet I can't say I clearly see the benefit of using Process Builder if you know how to write an apex trigger.
What would be a reason to go with Process Builder instead of a trigger? I understand that one doesn't need code coverage for process builder but I don't consider that a benefit.
I am also wondering if a lot of Process Builders add up over time if there's some sort of conflicts that they might impose on each other that becomes harder to debug?
apex process builder
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
asked Jan 15 at 17:47
ArthleteArthlete
919716
I went through a lot of different articles about Process Builder vs Triggers. Yet I can't say I clearly see the benefit of using Process Builder if you know how to write an apex trigger.
What would be a reason to go with Process Builder instead of a trigger? I understand that one doesn't need code coverage for process builder but I don't consider that a benefit.
I am also wondering if a lot of Process Builders add up over time if there's some sort of conflicts that they might impose on each other that becomes harder to debug?
apex process builder
apex process builder
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
asked Jan 15 at 17:47
ArthleteArthlete
919716
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
asked Jan 15 at 17:47
ArthleteArthlete
919716
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
edited Jan 15 at 18:17
Adrian Larson♦
108k19115244
108k19115244
asked Jan 15 at 17:47
ArthleteArthlete
919716
asked Jan 15 at 17:47
ArthleteArthlete
919716
asked Jan 15 at 17:47
ArthleteArthlete
919716
919716
1
This is similar to salesforce.stackexchange.com/questions/139983/… (full disclosure: I wrote an answer on that question, and it's my highest-voted answer at this time)
– Derek F
Jan 15 at 19:04
@DerekF Thanks for linking to your answer! That was a good addition to what the others said.
– Arthlete
Jan 15 at 20:34
add a comment |
1
This is similar to salesforce.stackexchange.com/questions/139983/… (full disclosure: I wrote an answer on that question, and it's my highest-voted answer at this time)
– Derek F
Jan 15 at 19:04
@DerekF Thanks for linking to your answer! That was a good addition to what the others said.
– Arthlete
Jan 15 at 20:34
1
1
This is similar to salesforce.stackexchange.com/questions/139983/… (full disclosure: I wrote an answer on that question, and it's my highest-voted answer at this time)
– Derek F
Jan 15 at 19:04
This is similar to salesforce.stackexchange.com/questions/139983/… (full disclosure: I wrote an answer on that question, and it's my highest-voted answer at this time)
– Derek F
Jan 15 at 19:04
@DerekF Thanks for linking to your answer! That was a good addition to what the others said.
– Arthlete
Jan 15 at 20:34
@DerekF Thanks for linking to your answer! That was a good addition to what the others said.
– Arthlete
Jan 15 at 20:34
add a comment |
3 Answers
3
active
oldest
votes
From my perspective, the benefit is primarily for those who do not have the knowledge or resources to build Apex. If you have the knowledge and resources, I would stick with Apex.
The main drawbacks are the poor error handling, and the fact that this feature makes it so easy to introduce errors through lack of knowledge. For example, checking that a parent record exists before checking if a field on it has a specific value. Using Apex does not fix these errors in and of itself, but the development cycle should force you to include null checks, etc.
Again, I would personally recommend you put the logic in Apex if choosing between these two and you have the skill to implement either/or. However, I would note that Workflow Rule is still a good fit for many simple field updates.
The one exception to the above would be if you want to post to chatter and include at-mentions. Using the ConnectAPI is not bulk safe, and so in this corner case Process Builder is radically more efficient than Apex.
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
Thank you, this is the kind of answer I was looking for!
– Arthlete
Jan 15 at 17:57
1
If you have more process builder on specific object then there will be chances to get CPU limit exceeded error
– Santanu Boral
Jan 15 at 18:29
1
Like having one trigger per object one should also stick to one process per object
– Pranay Jaiswal
Jan 15 at 19:07
This article slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB.
– RedDevil
Jan 16 at 4:12
1
Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress
– Eric
Jan 16 at 5:16
add a comment |
For orgs that have business logic that can be purely described in Process Builder and Validation Rules, the benefit is that you get faster deployment times, no need for unit tests, and can implement business logic faster (generally speaking). However, for many typical cases, mixing Process Builder and Triggers can cause excessive governor limit usage, and so mixing the two are generally not recommended by those with enough experience to have tales to tell.
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
add a comment |
There's an interesting discussion I found on reddit: https://www.reddit.com/r/salesforce/comments/8uupjs/am_i_wrong_to_hate_processbuilder/
I find the below pretty interesting from the stand point that one can turn off the process builder without touching any code(or being a developer). Where I work we have a very heavy deployment process that requires multiple Pull Requests even for the smallest code change. That is pretty slow and sometimes there might not be any devs available to approve a PR immediately.
Classified triggers are much more maintainable if you have a regular dev on staff. I work on really technical enterprise orgs and from my perspective avoiding PB just because it's PB is a huge mistake. There are things you can do in PB much faster (posting to chatter, for one) and making quick apex invocables that are launched for a specific process node (that you MAY want to disable as part of operations, so admin can go and turn that node off). They're easier to iterate (by design) than triggers - so not being able to refactor them is crippling the tool.
For mission critical objects, triggers only. For less mission critical mixture is fine. PB handles easy stuff (write values from parent to child, post to chatter, quick create simple records, easily assess record state and assign values from formula fields etc). For anything that needs reference data like Maps, uniqueness like Sets - those go in the trigger.
answered Jan 15 at 20:49
ArthleteArthlete
919716
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%2f246704%2fis-there-a-benefit-of-using-process-builder-vs-triggers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
From my perspective, the benefit is primarily for those who do not have the knowledge or resources to build Apex. If you have the knowledge and resources, I would stick with Apex.
The main drawbacks are the poor error handling, and the fact that this feature makes it so easy to introduce errors through lack of knowledge. For example, checking that a parent record exists before checking if a field on it has a specific value. Using Apex does not fix these errors in and of itself, but the development cycle should force you to include null checks, etc.
Again, I would personally recommend you put the logic in Apex if choosing between these two and you have the skill to implement either/or. However, I would note that Workflow Rule is still a good fit for many simple field updates.
The one exception to the above would be if you want to post to chatter and include at-mentions. Using the ConnectAPI is not bulk safe, and so in this corner case Process Builder is radically more efficient than Apex.
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
Thank you, this is the kind of answer I was looking for!
– Arthlete
Jan 15 at 17:57
1
If you have more process builder on specific object then there will be chances to get CPU limit exceeded error
– Santanu Boral
Jan 15 at 18:29
1
Like having one trigger per object one should also stick to one process per object
– Pranay Jaiswal
Jan 15 at 19:07
This article slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB.
– RedDevil
Jan 16 at 4:12
1
Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress
– Eric
Jan 16 at 5:16
add a comment |
From my perspective, the benefit is primarily for those who do not have the knowledge or resources to build Apex. If you have the knowledge and resources, I would stick with Apex.
The main drawbacks are the poor error handling, and the fact that this feature makes it so easy to introduce errors through lack of knowledge. For example, checking that a parent record exists before checking if a field on it has a specific value. Using Apex does not fix these errors in and of itself, but the development cycle should force you to include null checks, etc.
Again, I would personally recommend you put the logic in Apex if choosing between these two and you have the skill to implement either/or. However, I would note that Workflow Rule is still a good fit for many simple field updates.
The one exception to the above would be if you want to post to chatter and include at-mentions. Using the ConnectAPI is not bulk safe, and so in this corner case Process Builder is radically more efficient than Apex.
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
Thank you, this is the kind of answer I was looking for!
– Arthlete
Jan 15 at 17:57
1
If you have more process builder on specific object then there will be chances to get CPU limit exceeded error
– Santanu Boral
Jan 15 at 18:29
1
Like having one trigger per object one should also stick to one process per object
– Pranay Jaiswal
Jan 15 at 19:07
This article slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB.
– RedDevil
Jan 16 at 4:12
1
Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress
– Eric
Jan 16 at 5:16
add a comment |
From my perspective, the benefit is primarily for those who do not have the knowledge or resources to build Apex. If you have the knowledge and resources, I would stick with Apex.
The main drawbacks are the poor error handling, and the fact that this feature makes it so easy to introduce errors through lack of knowledge. For example, checking that a parent record exists before checking if a field on it has a specific value. Using Apex does not fix these errors in and of itself, but the development cycle should force you to include null checks, etc.
Again, I would personally recommend you put the logic in Apex if choosing between these two and you have the skill to implement either/or. However, I would note that Workflow Rule is still a good fit for many simple field updates.
The one exception to the above would be if you want to post to chatter and include at-mentions. Using the ConnectAPI is not bulk safe, and so in this corner case Process Builder is radically more efficient than Apex.
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
From my perspective, the benefit is primarily for those who do not have the knowledge or resources to build Apex. If you have the knowledge and resources, I would stick with Apex.
The main drawbacks are the poor error handling, and the fact that this feature makes it so easy to introduce errors through lack of knowledge. For example, checking that a parent record exists before checking if a field on it has a specific value. Using Apex does not fix these errors in and of itself, but the development cycle should force you to include null checks, etc.
Again, I would personally recommend you put the logic in Apex if choosing between these two and you have the skill to implement either/or. However, I would note that Workflow Rule is still a good fit for many simple field updates.
The one exception to the above would be if you want to post to chatter and include at-mentions. Using the ConnectAPI is not bulk safe, and so in this corner case Process Builder is radically more efficient than Apex.
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
answered Jan 15 at 17:54
Adrian Larson♦Adrian Larson
108k19115244
108k19115244
Thank you, this is the kind of answer I was looking for!
– Arthlete
Jan 15 at 17:57
1
If you have more process builder on specific object then there will be chances to get CPU limit exceeded error
– Santanu Boral
Jan 15 at 18:29
1
Like having one trigger per object one should also stick to one process per object
– Pranay Jaiswal
Jan 15 at 19:07
This article slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB.
– RedDevil
Jan 16 at 4:12
1
Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress
– Eric
Jan 16 at 5:16
add a comment |
Thank you, this is the kind of answer I was looking for!
– Arthlete
Jan 15 at 17:57
1
If you have more process builder on specific object then there will be chances to get CPU limit exceeded error
– Santanu Boral
Jan 15 at 18:29
1
Like having one trigger per object one should also stick to one process per object
– Pranay Jaiswal
Jan 15 at 19:07
This article slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB.
– RedDevil
Jan 16 at 4:12
1
Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress
– Eric
Jan 16 at 5:16
Thank you, this is the kind of answer I was looking for!
– Arthlete
Jan 15 at 17:57
Thank you, this is the kind of answer I was looking for!
– Arthlete
Jan 15 at 17:57
1
1
If you have more process builder on specific object then there will be chances to get CPU limit exceeded error
– Santanu Boral
Jan 15 at 18:29
If you have more process builder on specific object then there will be chances to get CPU limit exceeded error
– Santanu Boral
Jan 15 at 18:29
1
1
Like having one trigger per object one should also stick to one process per object
– Pranay Jaiswal
Jan 15 at 19:07
Like having one trigger per object one should also stick to one process per object
– Pranay Jaiswal
Jan 15 at 19:07
This article slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB.
– RedDevil
Jan 16 at 4:12
This article slideshare.net/ChrisBaldock2/using-the-right-tool-for-the-job is written by a CTA and is very helpful in pro's/con's of trigger vs workflows vs PB.
– RedDevil
Jan 16 at 4:12
1
1
Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress
– Eric
Jan 16 at 5:16
Not to mention PB is/was 8x slower than same thing done in triggers AND it is immune to CPI timeout. This means OB can run for > 60 seconds without failing and the very next line of code will throw the error. Causes all sorts of support nightmares with finger pointing the package as the culprit which causes a PM to demand we fix it. But I digress
– Eric
Jan 16 at 5:16
add a comment |
For orgs that have business logic that can be purely described in Process Builder and Validation Rules, the benefit is that you get faster deployment times, no need for unit tests, and can implement business logic faster (generally speaking). However, for many typical cases, mixing Process Builder and Triggers can cause excessive governor limit usage, and so mixing the two are generally not recommended by those with enough experience to have tales to tell.
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
add a comment |
For orgs that have business logic that can be purely described in Process Builder and Validation Rules, the benefit is that you get faster deployment times, no need for unit tests, and can implement business logic faster (generally speaking). However, for many typical cases, mixing Process Builder and Triggers can cause excessive governor limit usage, and so mixing the two are generally not recommended by those with enough experience to have tales to tell.
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
add a comment |
For orgs that have business logic that can be purely described in Process Builder and Validation Rules, the benefit is that you get faster deployment times, no need for unit tests, and can implement business logic faster (generally speaking). However, for many typical cases, mixing Process Builder and Triggers can cause excessive governor limit usage, and so mixing the two are generally not recommended by those with enough experience to have tales to tell.
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
For orgs that have business logic that can be purely described in Process Builder and Validation Rules, the benefit is that you get faster deployment times, no need for unit tests, and can implement business logic faster (generally speaking). However, for many typical cases, mixing Process Builder and Triggers can cause excessive governor limit usage, and so mixing the two are generally not recommended by those with enough experience to have tales to tell.
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
answered Jan 15 at 18:00
sfdcfoxsfdcfox
256k11201441
256k11201441
add a comment |
add a comment |
There's an interesting discussion I found on reddit: https://www.reddit.com/r/salesforce/comments/8uupjs/am_i_wrong_to_hate_processbuilder/
I find the below pretty interesting from the stand point that one can turn off the process builder without touching any code(or being a developer). Where I work we have a very heavy deployment process that requires multiple Pull Requests even for the smallest code change. That is pretty slow and sometimes there might not be any devs available to approve a PR immediately.
Classified triggers are much more maintainable if you have a regular dev on staff. I work on really technical enterprise orgs and from my perspective avoiding PB just because it's PB is a huge mistake. There are things you can do in PB much faster (posting to chatter, for one) and making quick apex invocables that are launched for a specific process node (that you MAY want to disable as part of operations, so admin can go and turn that node off). They're easier to iterate (by design) than triggers - so not being able to refactor them is crippling the tool.
For mission critical objects, triggers only. For less mission critical mixture is fine. PB handles easy stuff (write values from parent to child, post to chatter, quick create simple records, easily assess record state and assign values from formula fields etc). For anything that needs reference data like Maps, uniqueness like Sets - those go in the trigger.
answered Jan 15 at 20:49
ArthleteArthlete
919716
add a comment |
There's an interesting discussion I found on reddit: https://www.reddit.com/r/salesforce/comments/8uupjs/am_i_wrong_to_hate_processbuilder/
I find the below pretty interesting from the stand point that one can turn off the process builder without touching any code(or being a developer). Where I work we have a very heavy deployment process that requires multiple Pull Requests even for the smallest code change. That is pretty slow and sometimes there might not be any devs available to approve a PR immediately.
Classified triggers are much more maintainable if you have a regular dev on staff. I work on really technical enterprise orgs and from my perspective avoiding PB just because it's PB is a huge mistake. There are things you can do in PB much faster (posting to chatter, for one) and making quick apex invocables that are launched for a specific process node (that you MAY want to disable as part of operations, so admin can go and turn that node off). They're easier to iterate (by design) than triggers - so not being able to refactor them is crippling the tool.
For mission critical objects, triggers only. For less mission critical mixture is fine. PB handles easy stuff (write values from parent to child, post to chatter, quick create simple records, easily assess record state and assign values from formula fields etc). For anything that needs reference data like Maps, uniqueness like Sets - those go in the trigger.
answered Jan 15 at 20:49
ArthleteArthlete
919716
add a comment |
There's an interesting discussion I found on reddit: https://www.reddit.com/r/salesforce/comments/8uupjs/am_i_wrong_to_hate_processbuilder/
I find the below pretty interesting from the stand point that one can turn off the process builder without touching any code(or being a developer). Where I work we have a very heavy deployment process that requires multiple Pull Requests even for the smallest code change. That is pretty slow and sometimes there might not be any devs available to approve a PR immediately.
Classified triggers are much more maintainable if you have a regular dev on staff. I work on really technical enterprise orgs and from my perspective avoiding PB just because it's PB is a huge mistake. There are things you can do in PB much faster (posting to chatter, for one) and making quick apex invocables that are launched for a specific process node (that you MAY want to disable as part of operations, so admin can go and turn that node off). They're easier to iterate (by design) than triggers - so not being able to refactor them is crippling the tool.
For mission critical objects, triggers only. For less mission critical mixture is fine. PB handles easy stuff (write values from parent to child, post to chatter, quick create simple records, easily assess record state and assign values from formula fields etc). For anything that needs reference data like Maps, uniqueness like Sets - those go in the trigger.
answered Jan 15 at 20:49
ArthleteArthlete
919716
There's an interesting discussion I found on reddit: https://www.reddit.com/r/salesforce/comments/8uupjs/am_i_wrong_to_hate_processbuilder/
I find the below pretty interesting from the stand point that one can turn off the process builder without touching any code(or being a developer). Where I work we have a very heavy deployment process that requires multiple Pull Requests even for the smallest code change. That is pretty slow and sometimes there might not be any devs available to approve a PR immediately.
Classified triggers are much more maintainable if you have a regular dev on staff. I work on really technical enterprise orgs and from my perspective avoiding PB just because it's PB is a huge mistake. There are things you can do in PB much faster (posting to chatter, for one) and making quick apex invocables that are launched for a specific process node (that you MAY want to disable as part of operations, so admin can go and turn that node off). They're easier to iterate (by design) than triggers - so not being able to refactor them is crippling the tool.
For mission critical objects, triggers only. For less mission critical mixture is fine. PB handles easy stuff (write values from parent to child, post to chatter, quick create simple records, easily assess record state and assign values from formula fields etc). For anything that needs reference data like Maps, uniqueness like Sets - those go in the trigger.
answered Jan 15 at 20:49
ArthleteArthlete
919716
answered Jan 15 at 20:49
ArthleteArthlete
919716
answered Jan 15 at 20:49
ArthleteArthlete
919716
answered Jan 15 at 20:49
ArthleteArthlete
919716
919716
add a comment |
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%2f246704%2fis-there-a-benefit-of-using-process-builder-vs-triggers%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
1
This is similar to salesforce.stackexchange.com/questions/139983/… (full disclosure: I wrote an answer on that question, and it's my highest-voted answer at this time)
– Derek F
Jan 15 at 19:04
@DerekF Thanks for linking to your answer! That was a good addition to what the others said.
– Arthlete
Jan 15 at 20:34