The Basics of Salesforce Apex Trigger
To understand how to write Salesforce Apex Trigger, you need to understand some basics about what they are and what they do. By simple definition, Apex triggers are event managers. When you insert, update, delete, merge, insert, or delete a record linked to the trigger, the Salesforce system will execute that trigger event. There are two contexts in which Salesforce will execute a trigger; before and after. While the before trigger handles events that needs to be executed prior to the submission and commitment of a record to the database, the after-trigger handles events that need to be executed once a record is submitted and committed to the database. For instance you can have a trigger run prior the insertion of an object’s records into the database, once you have deleted a record, or even once you have restored a record from the recycle bin.
Writing your first Apex Trigger
First you have to appreciate that Salesforce has many user friendly features that can help you get through whatever function you want to create without having to write a code for it. This means that you may try running a function through the Salesforce user interface before going the programmatic way. Having understood this you can now acquaint yourself with the Salesforce programmer’s tools.
Resources Available for Use
When writing a Salesforce apex trigger, there are a number of objects (collections and variables) already set for you to work with in different contexts.
The Collections Include:
- The “trigger new” collection, which refers to the new records you are working with.
- The “trigger newMap” collection, which refers to the indexed (mapped) new records you are working with.
- The “trigger old” collection, which refers to the old or previous values of the current records. This collection is called upon in the event of a delete, undelete and an update.
- The “trigger oldMap” collection, which refers to the indexed (mapped) old values of the current records.
The variables available for use appear in two forms; true or false variables. This means that you ask yourself whether a certain action is true or false (applies to event or does not apply to event).
Ask, “Does this action apply to the event?” The action to which the answer TRUE is given is to be used while those to which the answer FALSE is given are to be discarded.
- Insert? –trigger isInsert
- Update? trigger isUpdate
- Delete? –trigger isDelete
- Undelete? –trigger isUndelete
- Merge? –trigger isMerge
- Upsert? –trigger is Upsert
Further you need to determine whether the action is a before or after action. Ask, “What type of action is this?” in this section only one consideration will answer to TRUE and the other to FLALSE.
- Before -trigger isBefore
- After -trigger isAfter
You may have noticed that Salesforce puts limits to about every feature or function; limits on data size, objects, fields, etc. the same happens when using Salesforce apex triggers. This means that the trigger new property only avails new records to work with and we may assume that the loop goes on without end. When using the Salesforce UI, you will be notified when you approach the limit, but when writing your own Salesforce apex trigger, you have to account for this on your own. You need to ensure that your code is able to handle a batch of records up to thousands of records without hitting the threshold. This means that you should consider how you write your triggers. You are to consider how you query added information and how many script statements you are execution for each record.
Trigger Logic
When writing your Salesforce apex trigger, you may very easily get stuck or over-code the solution. You need to be able to see that your code performs exactly the way you want it to function without interfering with other aspects of your code of code function. The best way to be able to manage with writing a logical and flowing Salesforce apex code without getting off track or getting stuck is to speak out aloud what you want to achieve of do. Speak the function, write it down, code it and go through your code to ensure that it is workable. Use salesforce trigger tutorial resources to gain more information.
Unit Tests
With any Salesforce apex trigger code, you have to run a test that checks the application of your new trigger to the production environment. This is the Unit test. Basically, it is meant to imitate how your apex code would be executed in a real production environment, whether it is applicable and whether the desired results can be achieved when using your apex code.
Structure Your Trigger
To write an executable trigger code, you need to abide by a specific general format. First you have to define what you are adding –a trigger in this case. Having established that what you are adding is a trigger, state the name of the trigger you are working with. Since the trigger has to be executing something –an object- you have to state the name of the object to be fired against. Lastly you need to state the database operation on which your trigger will fire – here the operations are insert, delete, undelete, and update.
Your Salesforce Apex Trigger Will Appear as Such
trigger AddChatterPostToParent on ChildObject__c (after insert, after update) {
/*trigger logic*/ }
The first part “trigger” states that this is a trigger, the “AddChatterPostToParent” is the trigger name, the “on” shows the direction of execution, the “ChildObject__c” is the object to be fired against, and the “insert after” and “update before” are the database operations on which the trigger will fire.
Salesforce.com is user friendly and finding your own way around the User Interface isn’t a hard thing. Much as writing your own first Salesforce Apex Trigger code isn’t an easy thing, you can always find your way around and get things done with a little learning. For further trigger information check out Salesforce trigger best practices.