Why do we need to update related records in an after trigger but not before?












1















Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?










share|improve this question



























    1















    Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?










    share|improve this question

























      1












      1








      1








      Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?










      share|improve this question














      Why do we need to write the logic to update a related record in an after trigger but not before? Update triggers(Before/After) will have both the record ID and the related record's ID so why can I not write the logic in a before trigger?







      apex trigger before-trigger after-trigger






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 15 hours ago









      User2529User2529

      336521




      336521






















          3 Answers
          3






          active

          oldest

          votes


















          3














          If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



          Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



          Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




          • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

          • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

          • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


          Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



          Conclusion:



          You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






          share|improve this answer
























          • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

            – sfdcfox
            13 hours ago











          • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

            – Derek F
            13 hours ago






          • 1





            Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

            – sfdcfox
            13 hours ago



















          2














          Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



          As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



          trigger CreateGuid on Contact (before insert) {
          ContactTriggerHelper.createGuidsForContacts(Trigger.new);
          }




          trigger UpdateGuidList on Contact (before insert) {
          ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
          }




          If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



          However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



          As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





          Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






          share|improve this answer































            0














            Basically you write an after trigger for cross object scenarios because one important reason that the related records might have some fields whose values are dependent on the parent record's values which we can only get after parent's values are saved to database. If you do in before trigger, parent's values are not yet saved and couldn't be made available for those dependent related records.






            share|improve this answer























              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
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f254752%2fwhy-do-we-need-to-update-related-records-in-an-after-trigger-but-not-before%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









              3














              If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



              Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



              Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




              • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

              • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

              • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


              Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



              Conclusion:



              You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






              share|improve this answer
























              • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

                – sfdcfox
                13 hours ago











              • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

                – Derek F
                13 hours ago






              • 1





                Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

                – sfdcfox
                13 hours ago
















              3














              If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



              Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



              Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




              • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

              • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

              • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


              Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



              Conclusion:



              You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






              share|improve this answer
























              • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

                – sfdcfox
                13 hours ago











              • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

                – Derek F
                13 hours ago






              • 1





                Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

                – sfdcfox
                13 hours ago














              3












              3








              3







              If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



              Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



              Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




              • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

              • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

              • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


              Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



              Conclusion:



              You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.






              share|improve this answer













              If I understand your question correctly, then you actually can take your related record update logic and put it in either a before or after trigger.



              Salesforce's suggestion is that before triggers should be used to update data on the records taking part in the trigger (the ones stored in trigger context variables), but it's just that... a suggestion.



              Keeping updates of related objects in after triggers (or not in before triggers) has a few benefits:




              • Following this advice helps logically separate the work done on object X itself, and the work done on the records Y and Z that are related to X

              • If you run into an issue (null pointer exceptions, validation exceptions, etc...) in a before trigger (or more accurately, before the after trigger is run), and have related record update logic in an after trigger, then you potentially won't spend time doing more work that will just be rolled back (compared to if your related record update logic were in a before trigger)

              • Related to the above point, this "fail fast" mechanism (and not doing ultimately meaningless work) means that you have less chance of running out of one of the resources monitored by the governor limits (which could end up masking another error).


              Another reason to avoid updating related records in before triggers is that related records can't take advantage of the "free update" that's available in before triggers (when making a change to a record stored in trigger.new and/or trigger.newMap)



              Conclusion:



              You could put your related record update logic into a before trigger, but you should think long and hard about whether or not that's really a good idea.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered 13 hours ago









              Derek FDerek F

              20.5k42253




              20.5k42253













              • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

                – sfdcfox
                13 hours ago











              • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

                – Derek F
                13 hours ago






              • 1





                Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

                – sfdcfox
                13 hours ago



















              • Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

                – sfdcfox
                13 hours ago











              • @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

                – Derek F
                13 hours ago






              • 1





                Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

                – sfdcfox
                13 hours ago

















              Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

              – sfdcfox
              13 hours ago





              Related records don't get a "free" update, just those in Trigger.new. Your "fail fast" is a good point, but not strictly from a governor-limits point of view; partial updates (which should always be used in a trigger) can cause governor limits to roll back during partially successful updates. It's still desirable to reduce the time needed on database record locks to avoid other errors, though.

              – sfdcfox
              13 hours ago













              @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

              – Derek F
              13 hours ago





              @sfdcfox I think you might have misread my point about the "free" update. I said that related records cannot take advantage of this. On your "partial updates" point: Are you talking about the feature that landed in Summer '18? Either way, I'm unfamiliar with that feature and it looks like I have some reading to do.

              – Derek F
              13 hours ago




              1




              1





              Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

              – sfdcfox
              13 hours ago





              Oh, fair enough on the first point. Probably best to not even mention it, as it's not relevant either way? In regards to governor limits, if you use the allOrNone partial update (e.g. Database.insert(records, false)), if there's any addError messages within the transaction, the governor limits are partially rolled back to before that statement and the non-errored records are retried. It's always been this way, although not a lot of people seem to know/understand how this works.

              – sfdcfox
              13 hours ago













              2














              Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



              As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



              trigger CreateGuid on Contact (before insert) {
              ContactTriggerHelper.createGuidsForContacts(Trigger.new);
              }




              trigger UpdateGuidList on Contact (before insert) {
              ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
              }




              If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



              However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



              As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





              Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






              share|improve this answer




























                2














                Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



                As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



                trigger CreateGuid on Contact (before insert) {
                ContactTriggerHelper.createGuidsForContacts(Trigger.new);
                }




                trigger UpdateGuidList on Contact (before insert) {
                ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
                }




                If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



                However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



                As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





                Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






                share|improve this answer


























                  2












                  2








                  2







                  Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



                  As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



                  trigger CreateGuid on Contact (before insert) {
                  ContactTriggerHelper.createGuidsForContacts(Trigger.new);
                  }




                  trigger UpdateGuidList on Contact (before insert) {
                  ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
                  }




                  If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



                  However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



                  As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





                  Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.






                  share|improve this answer













                  Using the after trigger event is strongly recommended, but not necessary, for updating related records, because before trigger events can modify the records in an unpredictable order. Waiting until the records have been committed to the database reduces this possibility. Note that there are some specific scenarios where it is even desirable to work with related records in a before trigger, such as if you want to create parent records if they are missing.



                  As a simple example, consider these two "triggers" (pseudo-code) that deal with contacts:



                  trigger CreateGuid on Contact (before insert) {
                  ContactTriggerHelper.createGuidsForContacts(Trigger.new);
                  }




                  trigger UpdateGuidList on Contact (before insert) {
                  ContactTriggerHelper.updateGuidOnAccounts(Trigger.new);
                  }




                  If CreateGuid runs first, the Account will show the correct values by the end of the transaction. However, if UpdateGuidList runs first, the values will still be null. We cannot strictly predict ahead of time which trigger will run first.



                  However, if we move UpdateGuidList to an after insert event, we guarantee that the contacts will have the correct data before the update to the related records occur. This is generally desirable behavior.



                  As an alternative to this problem, what if one trigger automatically assigns a value to the lookup field, and another updates the record? In that case, the wrong record could get updated, and it would be troublesome to even debug, because the order of operations are not guaranteed between trigger events that occur at the same time.





                  Unless you know for sure that nobody will ever depend on the order of operations of the triggers, or that the order of execution does not matter, stick with the after trigger event for updating related records. It is much easier to use after trigger events all the time and not have to guess about possible side effects than it is to risk random or periodic logic failures because someone did not take your trigger into account when adding more logic elsewhere.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 13 hours ago









                  sfdcfoxsfdcfox

                  260k12207451




                  260k12207451























                      0














                      Basically you write an after trigger for cross object scenarios because one important reason that the related records might have some fields whose values are dependent on the parent record's values which we can only get after parent's values are saved to database. If you do in before trigger, parent's values are not yet saved and couldn't be made available for those dependent related records.






                      share|improve this answer




























                        0














                        Basically you write an after trigger for cross object scenarios because one important reason that the related records might have some fields whose values are dependent on the parent record's values which we can only get after parent's values are saved to database. If you do in before trigger, parent's values are not yet saved and couldn't be made available for those dependent related records.






                        share|improve this answer


























                          0












                          0








                          0







                          Basically you write an after trigger for cross object scenarios because one important reason that the related records might have some fields whose values are dependent on the parent record's values which we can only get after parent's values are saved to database. If you do in before trigger, parent's values are not yet saved and couldn't be made available for those dependent related records.






                          share|improve this answer













                          Basically you write an after trigger for cross object scenarios because one important reason that the related records might have some fields whose values are dependent on the parent record's values which we can only get after parent's values are saved to database. If you do in before trigger, parent's values are not yet saved and couldn't be made available for those dependent related records.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered 15 hours ago









                          7'7'7'7'

                          1075




                          1075






























                              draft saved

                              draft discarded




















































                              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.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f254752%2fwhy-do-we-need-to-update-related-records-in-an-after-trigger-but-not-before%23new-answer', 'question_page');
                              }
                              );

                              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







                              Popular posts from this blog

                              How to make a Squid Proxy server?

                              Is this a new Fibonacci Identity?

                              19世紀