Apex Triggers

Salesforce uses many programming technologies – among them Apex is one significant coding language that is used for various applications. Salesforce triggers are developed with Apex and so termed as Apex triggers. Their function enables freedom to do customized actions like modifying Salesforce records.

A Salesforce trigger here is considered as the Apex code which is executed before or after certain kinds of operations like –

• Insert
• Delete
• Undelete
• Merge
• Update
• Upsert

Upon these particular events, the triggers are fired out in Salesforce.

Here is the simple way to understand when and where Salesforce triggers work. Salesforce includes databases to deal with storage of different types of data, data analysis, etc. Before inserting the object’s records in the database, you need to run a trigger which imposes codes to include them. They are also run after deleting records, or fixing records from the recycle bin.

Types of Salesforce Triggers

Actually, there are no different types of triggers – but as the triggers are used before or after certain operations, they are considered to be of two types.

• Before triggers
• After triggers

Before triggers – These triggers run before the activity like updating or inserting a record into a database.

After triggers – These triggers are run for accessing the field values set by the system. They are also used to affect the changes in the records. For instance, after triggers are often used when dealing with audit tables and also when you handle asynchronous events with a queue. These after-triggers are considered read-only.

Syntax of a Trigger

The definition of a trigger starts with the trigger catchphrase and then followed by the trigger name.

trigger < TriggerName> on ObjectName (< Trigger_Events>)

{

Any required code is written here.

}

The Trigger_Events can be a comma-separated list of any events like – before insert, before update, before delete, after insert, after delete, after update, or after undelete.

Considerations for implementation of Triggers in Salesforce

Certain considerations are to be kept in mind when implementing Salesforce triggers. Here are some of them.

• Before and after insert are fired by upsert triggers. Also, they fire the before and after update triggers whenever applicable.
• For the losing records, before and after delete are fired by the merge triggers and for the winning records before and after update triggers are considered.
• If the record has been undeleted and the trigger is performed after it, then it works only with certain specific objects.
• Till the end of the trigger, no records of field history are made. So, you cannot notice the history of current transactions when you ask for the field history in a trigger.
• The permissions of the current user are required to know the field history tracking. For instance, if a user doesn’t have a right to edit an object, but a trigger is activated still by the user to change an object with enabling the history tracking, then there will be no records of the history of the change.
• Asynchronous calls are to be made to avoid the blocking of the trigger process when waiting for the response of external service.

Trigger Context Variables

There are certain context variables which implicit the triggers – they help developers to access the run-time context.

• Trigger.isBefore – It gives true if this trigger ends before any record was spared.
• Trigger.isAfter – It mentions true value if this trigger ends after all records were spared.
• Trigger.isInsert – It avails true if it was fired for some insert operation, from the Apex, API, or the Salesforce User Interface.
• Trigger.isUpdate – It gives a true value when an update operation is done upon using this trigger.
• Trigger.isDelete – It gives genuine answer when one uses this trigger during any delete operations through Apex, API, or Salesforce user interface.
• Trigger.isUndelete – It gives a genuine things when one fires this trigger after recovering a record from the Recycle Bin.
• Trigger.new – new versions of the sObject records are showed with the help of it.
• Trigger.old – It provides a list of sObject records’ old versions. However, the list is only available in update and delete triggers.
• Trigger.newMap – It gives a map of IDs for the sObject records’ new versions. However, it is only found in before update, after update, after insert, and after undelete triggers.
• Trigger.oldMap – It gives a map of IDs to the sObject records’ old versions and is there in update and delete triggers.
• Trigger.oldMap – It gives a map of IDs to the sObject records’ old versions and is there in update and delete triggers.
• Trigger.size – It gives the total number of records (both old and new records) upon calling.

Having an idea on these triggers is very much important for developers and other Salesforce users to manage the appropriate functions accurately.

Bulk Triggers

At some instances, bulk operations are in need to demand certain applications – bulk triggers are helpful at this time. However, mostly, the Salesforce triggers are all bulk triggers as multiple records can be processed at a single point of time. However, when planning to manipulate and manage huge data and multiple processes, then it is necessary to go for bulk triggers accordingly. They enable operations like – Lightning platform Bulk API calls, Data import, and Mass actions like record owner changes and deletes.

Trigger enabled development is involved in Salesforce. So, each operation handled by the user on the Salesforce user interface platform is done simply – but, there is an excellent contribution of these Salesforce triggers to ensure appropriate function and operation accurately and efficiently.

Check out Here Salesforce Triggers Interview Questions