Triggers and Recovered Records
The after undelete trigger event only works with recovered records—
that is, records that were deleted and then recovered from the Recycle
Bin through the undelete DML statement.
These are also called undeleted records.
The after undelete trigger events only run on top-level objects.
For example, if you delete an Account, an Opportunity may also be
deleted.
When you recover the Account from the Recycle Bin, the Opportunity is
also recovered.
If there is an after undelete trigger event associated with both the
Account and the Opportunity, only the Account after undelete trigger
event executes.
The after undelete trigger event only fires for the following objects:
Account
Asset
Campaign
Case
Contact
ContentDocument
Contract
Custom objects
Event
Lead
Opportunity
Product
Solution
Task
Operations That Don't Invoke Triggers
Triggers are invoked for data manipulation language (DML) operations that the
Java application server initiates or processes. Therefore, some system bulk
operations don't invoke triggers
Example--Cascading delete operations, records that did not initiate
a delete don't cause trigger evaluation.
Cascading updates of child records that are reparented as a result of a merge
operation
Mass campaign status changes
Mass division transfers
Mass address updates
Mass approval request transfers
Mass email actions
Modifying custom field data types
Renaming or replacing picklists
Managing price books
Changing a user's default division with the transfer division option
checked
Changes to the following objects:
BrandTemplate
MassEmailTemplate
Folder
Update account triggers don't fire before or after a business account
record type is changed to person account (or a person account record
type is changed to business account.)
Update triggers don’t fire on FeedItem when the LikeCount counter
increases.
Fields Not Updateable in Before Triggers
Few field values are set during the system save operation, which occurs
after before triggers have fired.
As a result, these fields cannot be modified or accurately detected
in before insert or before update triggers.
Examples are--Task.isClosed
Opportunity.amount
Opportunity.ForecastCategory
Opportunity.isWon
Opportunity.isClosed
Contract.activatedDate
Contract.activatedById
Case.isClosed
Solution.isReviewed
Id (for all records)**
createdDate (for all records)**
lastUpdated (for all records)
Event.WhoId (when Shared Activities is enabled)
Task.WhoId (when Shared Activities is enabled)
* When Opportunity has no line items, Amount can be modified by
a before trigger.
** Id and createdDate can be detected in before update triggers, but cannot be
modified.
Fields Not Updateable in After Triggers
The following fields can’t be updated by after insert or after update triggers.
Event.WhoId
Task.WhoId
Considerations for Event DateTime Fields in Insert and Update Triggers
We recommend using the following date and time fields to create or update
events.
When creating or updating a timed Event, use ActivityDateTime to avoid
issues with inconsistent date and time values.
When creating or updating an all-day Event, use ActivityDate to avoid
issues with inconsistent date and time values.
We recommend that you use DurationInMinutes because it works with
all updates and creates for Events.
Operations Not Supported in Insert and Update Triggers
Manipulating an activity relation through
the TaskRelation or EventRelation object, if Shared Activities is enabled
Manipulating an invitee relation on a group event through
the Invitee object, whether or not Shared Activities is enabled
Considerations for Update Triggers
Field history tracking honours the permissions of the current user.
If the current user doesn’t have permission to directly edit an object or
field, but the user activates a trigger that changes an object or field with
history tracking enabled, no history of the change is recorded.
