14

It is general best practice to consolidate. The main advantage here is control of execution. When you have 2 triggers on the account object, there is no way to know or control which fires first. If however, you move those triggers into a utility class, called by a single account trigger, you now can control the order in which they are fired. 2 Trigger ...


10

A save writes your changes to the database, however at this point these changes are only visible to you within your transaction scope. The database has also generated undo information which contains the old values of your transaction which can be used to rollback your modifications. A commit ends the current transaction and makes permanent all changes ...


9

What is happening is that you are actually using an Initialization Block. See Static and Instance Methods, Variables, and Initialization Code (Using Initialization Code). Using Initialization Code Instance initialization code is a block of code in the following form that is defined in a class. { //code body } The instance initialization ...


9

I set up a fresh org to test this scenario out and the behavior is as I would expect. Account trigger fires before Contact, and the child records are not defined in the Account triggers at all. Account Trigger trigger Account on Account (before insert, after insert) { if (trigger.isBefore) { system.debug('Account beforeInsert'); } ...


8

init event of the child component will called long before the parent's. Add aura:doneRendering event in the child component and access the list in in the child. Order in which init fired is mentioned in the developer guide and in this article too. When the component tree is ready, the init event is fired for all the components, starting from the ...


7

As @Bachovski pointed out, there is no way to control the execution order. In the case of your 5 account triggers, you would likely want to combine all 5 triggers into a single trigger that calls a utility class with 5 methods. Each method contains the logic of your old triggers. This way, you do have control over the order of execution. Utility Class ...


7

It's described nicely in the documentation: The order of execution isn’t guaranteed when having multiple triggers for the same object due to the same event. For example, if you have two before insert triggers for Case, and a new Case record is inserted that fires the two triggers, the order in which these triggers fire isn’t guaranteed. So there ...


7

From SF documentation: The order in which individual actions and types of actions are executed is not guaranteed. However, field update actions are executed first, followed by other actions. http://na6.salesforce.com/help/doc/en/workflow_rules_considerations.htm So basically, you can be assured that the field updates will occur first, but the order of ...


7

Any field update from a Workflow Rule/Process Builder/Apex Trigger will cause update triggers on affected records to fire.


6

The closest you can get to last within the same transaction is to write a process. First, create an @InvocableMethod: public class CleanUpInvocable { @InvocableMethod(label='Clean Up Actions' description='Performs actions on records after all triggers have fired.') public static void processRecords(Id[] ids) { // ... Do stuff here } } ...


6

Technically, this problem affects certain types of inter-controller communications. I believe I've run into this bug before, but support said that there was no impending fix for the problem. You shouldn't try to attempt controller communications before all of them are constructed, simply because the order of constructors is not necessarily dependable, except ...


6

The content of the email sent out to the recipient can't be changed by changing the content in EmailMessage record. When you do the change in before insert, it modifies only the EmailMessage record and the original message sent out is not altered. For the inbound message, the content customer sent will be received as is to our outlook/gmail inbox. But the ...


6

Outbound messages are executed asynchronously. When a workflow rule causes an outbound message to fire, it's simply placed into a queue for later execution. A future method would fire before an outbound message would most likely fire off before an outbound message would have a chance to go, and the row-locking algorithm would make sure that the two play nice ...


6

let me guess, that records, that are sent to Apex are sent from Process as "Select the Case record that started your process". According to the Order of Execution process is launched after after triggers. And if you are sending context records, looks like they all have "isReadOnly" flag on the sObject records. This flag is responsible for causing the ...


5

There is a distinction between standard validation rules (number fields must be numbers, etc) and custom validation rules (discount > 20) Triggers need to have valid sobjects passed to them, hence data scrubbing is done by SFDC prior to before trigger execution. Since before triggers can modify the sobject, the custom validation rules need to execute ...


5

Yes, fields set in a before trigger will generally* be available for the other two steps you listed. From the Apex Developer Guide (emphasis added): Triggers and Order of Execution: When you save a record with an insert, update, or upsert statement, Salesforce performs the following events in order. Note Before Salesforce executes ...


5

A formula field can only be "executed" when the record is either opened, requeried, or refreshed. If you've performed a new record save DML operation, you'll need to do a controller page refresh before that field can be populated for use with your email template when you do the "send". Important to note that I'm making the assumption that you're likely ...


4

I don't fully follow your exact use case, but instead of having two triggers on the same object, you should create one trigger and have the before and after logic within it. Triggers have set execution flow within the trigger itself, but if you have two triggers on the same object, one of them fires and completes, then the second fires and completes. There ...


4

The code originally quoted is a bad example, because we do actually know what the values of selectedValue and editMode will be; with a private setter, editMode won't have a value until set by the other setter. However, consider this controller: public class CompCont { public String a { get; set { a = (b == null)? 'Hello': value } } public String b { ...


4

The better approach in this case is to use Upsert API Call instead of Insert. Trigger are designed to throw exception when there is error and we will not be able to change it. https://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_upsert.htm


4

The Apex Language Utilities has a Stopwatch Class that may do what you're looking for. It can be used within Apex as a timer of sorts. The complete code for all of the utilities is available from a repository on Github. The code for the StopWatch Class is shown below. /* ============================================================ * This code is part of ...


4

Email alerts are sent AFTER a database commit. Until the commit takes place, it makes no sense to send the email to someone telling them it's occurred. That's why step 11 is to perform the field updates, which can cause additional actions to follow.


4

It's calculated on demand, and thus does not participate in the order of execution. In practice, that means it calculated each time it is queried from the database. In the context of a DML operation, each formula is recalculated while loading Trigger.old and Trigger.new, before evaluating validation, assignment, escalation, and workflow rules, and while ...


4

The trigger(s) (and it is both Trigger 'A' and Trigger 'B' in your example) are only being executed once after the workflow field update because that's how Salesforce has decided to make things work. If you go look at the official order of execution, you'll see the following (emphasis mine) If there are workflow field updates, updates the record again....


4

Short Answer Workflow rules execute "simultaneously," and therefore have no defined order. Long Answer Workflow rules are evaluated in arbitrary order, and for each one that matches, its actions are queued for execution. Then, all queued actions execute. Finally, if any workflow rule requested a re-evaluation on record update, and the record was updated, ...


4

This seems to be the expected behavior considering you are updating the same field from a workflow update too. If you see the Triggers and Order of Execution documentation, and refer to the below excerpt from the documentation, this seems to be coming into picture here. Trigger.old contains a version of the objects before the specific update that fired ...


3

Things that are executed asynchronously are serialized into a binary format at the moment they are called, then placed into a queue. This queue is then executed later. I wrote a proof of concept for this once before, but I don't have it handy. Therefore, it's easily possible that the records could change between the time the function is called and when it ...


3

If the request came from a standard UI edit page, Salesforce runs system validation to check the record for: Compliance with layout-specific rules Required values at the layout level and field-definition level Valid field formats Maximum field length What this means is that if the request was run from a VF page as opposed to code inside ...


3

Relaying a response from Michael Alderete - Technical writer for the Salesforce docs team. Slightly modified for context. While I believe all of the behavior you’ve described [...] is expected, I don’t think you’re misinterpreting the docs. You’ve found an area that could be documented a little more clearly. This is expected behavior. The page-level ...


3

Very astute question! The answer is number 2. You want to put your boolean in your trigger where the class is called from. You'll need a trigger utility class to hold the boolean. This is a large part of why trigger platforms are so useful, particularly ones that have a "trigger main" that acts as a distribution class that follows the logic of a regular base ...


Only top voted, non community-wiki answers of a minimum length are eligible