What is Trigger?

A trigger is Apex code that executes before or after the following types of operations:

  1. insert
  2. update
  3. delete
  4. merge
  5. upsert
  6. undelete(Only After)

There are two types of triggers:

1) Before triggers are used to update or validate record values before they’re saved to the database.

2) After triggers are used to access field values that are set by the system (such as a record’s Id or LastModifiedDate field), and to effect changes in other records, such as logging into an audit table or firing asynchronous events with a queue.

The records that fire the after trigger are read-only.

Triggers can also modify other records of the same type as the records that initially fired the trigger. For example,

If a trigger fires after an update of contact A, the trigger can also modify contacts B, C, and D.Because triggers can cause other records to change, and because these changes can, in turn, fire more triggers, the Apex runtime engine considers all such operations a single unit of work and sets limits on the number of operations that can be performed to prevent infinite recursion. See Understanding Execution Governors and Limits


Why we use trigger?

Some time we need to change in parent record information or child record information or related record information. So to do this we need to write trigger.

By writing trigger

  • we can run our apex code and do what you want to do by custom code.
  • Work flow can only do more than just simple field updates, task create , outbound messaging and emails.

Workflow can’t do below task :

  • Your workflow can’t create or update a separate object!
  • You’re not allowed to reference certain fields, like Owner.Name (why Salesforce, why!)

How to create Trigger in Salesforce?

For Custom object

  1. From Setup, click Create | Objects and click the name of the object you just created.
  2. In the triggers section, click New.
  3. In the trigger editor, delete the default template code and enter this trigger definition:

Apex Code Syntax:

trigger on (before insert,before update ,before delete, after update,after insert , afterdelete,after undelete ){


For Native Object:

  1. From Setup, click Customize | Click on object and find the trigger link and then click on new button.

There are some variable by which you can get the record’s.

  1. Trigger.new –> Returns a list of the new versions of the sObject records.
  2. Trigger.old –> Returns a list of the old versions of the sObject records.
  3. Trigger.newMap –> A map of IDs to the new versions of the sObject records.
  4. Trigger.oldMap –> A map of IDs to the old versions of the sObject records.
  5. size –> The total number of records in a trigger invocation, both old and new.


Below is Table by which you can know which variable give you record in which event.

Variable Name Trigger.new Trigger.Old Trigger.newMap Trigger.oldMap
before insert Yes null null null
after insert Yes null Yes null
before update Yes Yes Yes Yes
after update Yes Yes Yes Yes
before delete null Yes null Yes
after delete null Yes null Yes
after undelete Yes null Yes null


*Be aware of the following considerations for trigger context variables:

1) trigger.new and trigger.old cannot be used in Apex DML operations.

2) You can use an object to change its own field values using trigger.new, but only in before triggers. In all after triggers, trigger.new is not saved, so a runtime exception is thrown.

3) trigger.old is always read-only.

4) You cannot delete trigger.new.

For More info


Controlling Recursive Triggers | How to invoke Trigger only once



Best Practices :

  • There should only be one trigger for each object.
    1. https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices
  • Avoid complex logic in triggers. To simplify testing and resuse, triggers should delegate to Apex classes which contain the actual execution logic. See Mike Leach’sexcellent trigger template for more info.
  • Bulkify any “helper” classes and/or methods.
  • Trigers should be “bulkified” and be able to process up to 200 records for each call.
  • Execute DML statements using collections instead of individual records per DML statement.
  • Use Collections in SOQL “WHERE” clauses to retrieve all records back in single query
  • Use a consistent naming convention including the object name (e.g., AccountTrigger)
  • Bulkify your Code
  • Avoid SOQL Queries or DML statements inside FOR Loops
  • Using Collections, Streamlining Queries, and Efficient For Loops
  • Streamlining Multiple Triggers on the Same Object
  • Querying Large Data Sets
  • Use of the Limits Apex Methods to Avoid Hitting Governor Limits
  • Use @future Appropriately
  • Writing Test Methods to Verify Large Datasets
  • Avoid Hardcoding IDs