Scribd
Upload
13 views

Apex Trigger Extra Topic

The document discusses triggers and recovered records in Salesforce. After undelete triggers only run on recovered records. Certain system operations and field changes do not cause triggers to run. Fields cannot be modified in all trigger contexts.

Uploaded by

shubhamchavhan0143
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
13 views

Apex Trigger Extra Topic

The document discusses triggers and recovered records in Salesforce. After undelete triggers only run on recovered records. Certain system operations and field changes do not cause triggers to run. Fields cannot be modified in all trigger contexts.

Uploaded by

shubhamchavhan0143
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

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.

You might also like