Apex can be invoked
through the use of triggers. Apex triggers enable you to perform custom actions
before or after changes to Salesforce
records, such as insertions, updates, or deletions.
A trigger is
Apex code that
executes before or after the following types of operations:
- insert
- update
- delete
- merge
- upsert
- undelete
For example, you can have a trigger run before an object's records are inserted into the
database, after records have been deleted, or even after a record is restored from the Recycle Bin.
You can define triggers for top-level standard objects that support triggers, such as a
Contact or an Account, some standard child objects, such as a CaseComment, and custom objects.
To define a trigger, from the object management settings for the object whose triggers you
want to access, go to Triggers.
There are two types of triggers:
-
Before triggers are used to update or validate record values before they’re
saved to the database.
-
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 Execution Governors and Limits.
Additionally, if you update or delete a record in its before trigger, or delete a record in
its after trigger, you will receive a runtime error. This includes both direct and indirect
operations. For example, if you update account A, and the before update
trigger of account A inserts contact B, and the after
insert trigger of contact B queries for account A and
updates it using the DML update statement or database
method, then you are indirectly updating account A in its before trigger,
and you will receive a runtime error.
Implementation Considerations
Before creating triggers, consider the following:
-
upsert triggers fire both before and after
insert or before and after update triggers as appropriate.
-
merge triggers fire both before and after
delete triggers for the losing records and
before update triggers for the winning record
only. See Triggers and Merge Statements.
- Triggers that execute after a record has been undeleted only work with specific objects.
See Triggers and Recovered Records.
- Field history is not recorded until the end of a trigger. If you query field history in
a trigger, you will not see any history for the current transaction.
-
Field history tracking honors the permissions of the
current user. If the current user doesn't have permission to directly edit an object or
field, but they activate a trigger that changes an object or field with history tracking
enabled, no history of the change is recorded.
- In API version 20.0
and earlier, if a Bulk API request causes
a trigger to fire, each chunk of 200 records for the trigger to process is split
into chunks of 100 records. In Salesforce
API version 21.0
and later, no further splits of API chunks occur.
If a Bulk API request
causes a trigger to fire multiple times for chunks of 200 records, governor
limits are reset between these trigger invocations for the same HTTP
request.