Before Mode: Before the record is saving into the database, it will fire. After Mode: After the record is saved into the database (doesn’t commit at this point of time), it will fire.
Before | After |
---|---|
before insert | after insert |
before update | after update |
before delete | after delete |
after undelete |
Note: before undelete event is not available.
To capture the runtime information we use trigger context variables.
Below context variables will return either true or false.
Apex Trigger Collections availability for the different events –
Events | trigger.old | trigger.oldMap | trigger.New | trigger.NewMap |
---|---|---|---|---|
before insert | No | No | Yes | No |
after insert | No | No | Yes | Yes |
before update | Yes | Yes | Yes | Yes |
after update | Yes | Yes | Yes | Yes |
before delete | Yes | Yes | No | No |
after delete | Yes | Yes | No | No |
after undelete | No | No | Yes | Yes |
Read/Write access over the trigger collections on different events –
Events | trigger.old | trigger.oldMap | trigger.New | trigger.NewMap |
---|
before insert NA NA Read/Write NA
after insert NA NA Read Only Read Only
before update Read Only Read Only Read/Write Read Only
after update Read Only Read Only Read Only Read Only
before delete Read Only Read Only Read Only Read Only
after delete Read Only Read Only Read Only Read Only
after undelete Read Only Read Only Read Only Read Only
Before Triggers – To perform the validations we should use before triggers.
If you are updating any field on the same object on which you are writing the trigger and no need to explicitly include the DML statements (already due to DML operation only trigger fire and it is still in progress at this point of time.)
After Triggers – If you are dealing with relationship records and if you need record id in these situations we should use after trigger (in before insert record doesn’t contain the record id).
We cannot control the order of execution in this situation. It is recommended to have only one trigger per one object.
Note: We can keep the logic of the apex trigger in an apex class and can invoke from that class.
If we perform update operation on the record in after update event logic recursive triggers will arise. Using static Boolean variable in an apex class (we should not keep static Boolean variable inside of the trigger) we can avoid recursive triggers.
See the below example: Note: To analyse the code copy it and paste it in notepad for the convenience.
public class TriggerUtility {
//Below is the example for the future method –
@future(callout = true)
public static void processAsync(primitive parameters) {
//Logic to insert/update the standard/custom object.
}
Relationship between ChildObjectc and ParentObjectc objects is Lookup relationship. In case of lookup relationship if we delete the parent object record in child object only the relationship field value will be removed (child records won’t be deleted).
But client has a requirement to delete the child object records. How to achieve this?
Write an apex trigger to achieve this functionality.
We should take before delete event. If we take after delete relationship will broke up b/w parent and child object records.,
Trigger ParentTrigger on ParentObject__c(before delete) {
Note: – For delete events only trigger.old and triggger.oldMap will be available. – trigger.old holds old versions of the records but if we mention that in SOQL query salesforce will automatically convert those records into ids.
List childLst = [select id, Parent_Object__c from ChildObject__c where Parent_Object__c in: trigger.old];
delete childLst;
}
Order of execution in sales force
Prepare the record for insert/update operation.
It will replace all the old field values with new field values.
If the request is coming form UI all the system validations will execute –
Custom Validations and again system validation rules will fire (Page Layout level validations won’t fire at this point of time)
Record will be saved into the database but doesn’t not commit.
In case of Workflow Rule Field updates again before triggers and after triggers fire one more time
Validation rules will fire first then workflow rules will fire. So, the answer is 100 (Even though there is a validation rule because of the workflow rule it will accept 100 in the amount field).
There is a workflow rule which will fire if amount > 100 and will update amount field to 100. One of user saved the record by giving value as 1000.It will throw the validation error because after the workflow field update before triggers fire one more time.