Skip to main content
Full Circle Insights

Response Management Triggers

The Response Management Trigger Framework

Note: This article is intended for advanced Salesforce admins, IT and developers.

The Response Management application uses a sophisticated trigger framework based on the concepts found in the book "Advanced Apex Programming in Salesforce".  As such, it captures all trigger types (before/after, insert/update/delete/undelete) on the multiple objects. However, most of these triggered events are ignored. This article outlines the key functionality that takes place on each of these triggers. Refer to the article How Full Circle Interacts with Salesforce  for a description of the functionality of the response management application itself.

Note that when the Response Management application is disabled, all triggers exit immediately.

Reentrancy

One of the advantages of using a trigger framework is that it allows us to minimize reentrancy issues - multiple invocations of triggers that is the primary cause of excessive CPU time usage. When the response management application performs a database operation, most all of the response management triggers are disabled to prevent it from reacting to its own DML operation. In addition, before inserting or updating a standard object, Response Management increments an "Admin Update Counter" field to allow declarative constructs (workflows, processes, flows) or external Apex to recognize a Response Management update and thus bypass any operations that don't need to monitor fields changed by our application. This is allows other applications or declarative contructs to eliminate reentrancy issues as well.

In our experience, the most common code related issue relates to the fact that we may update CampaignMembers (the active response) during a before update trigger on leads and contacts. Any code or process that, during a CampaignMember update, attempts to update a lead or contact, may fail (you cannot update a lead or contact during a before trigger). This can easily be avoided by using the admin update counter to detect our update and either avoid the update, or do so in an async context.

Standard Object Trigger to Functionality Mapping

The following describes the primary functionality associated with each standard object trigger that is actually used by the Response Management. Note that some trigger types have multiple functions attached.

Event and task triggers in Response Management exist but are not currently used (they are part of a possible future product feature and currently exist immediately).

Account Triggers

Account triggers only apply to person accounts, in which case they perform the same operations as their corresponding contact triggers. See Contact triggers for more information.

Campaign Triggers

Trigger type Functionality
Before Insert Initializes Response Management fields
Before Delete Update lead/contact status after deletion of active responses or blocks campaign deletion if active responses exist (based on org configuration)

CampaignMember Triggers

Trigger type Functionality
Before Insert and Before Update

Response evaluation sequence. Processing depends on org configuration.

Update status last set on status change

After Insert Complete opportunity association started during a Before Insert operation
After Insert and After Update Scoring (based on org configuration)
Before Update Async command requests are queued
After Delete Update lead/contact status after deletion of an active response
Before Update, Before Insert and Before Delete If any date field has changed, mark the date for a DST rebuild (if DST is enabled)
After Insert and After Update Queue up async custom funnel events if present

Contact Triggers

Trigger type Functionality
Before Insert Set default status
Before Update

If an active response exists, update and sync the active response

Depending on org configuration, send out notifications and perform post-assignment actions (including updating first owner/assigned info on active responses)

Queue up asynchronous commands

After update Perform Score and Active Status reactivation if configured
After delete Perform any post-merge operations

Lead Triggers

Trigger type Functionality
Before Insert Set default status
Before Update

If an active response exists, update and sync the active response

Depending on org configuration, send out notifications and perform post-assignment actions (including updating first owner/assigned info on active responses)

Queue up asynchronous commands

After update

Perform Score and Active Status reactivation if configured

Perform post-conversion operations

After delete Perform any post-merge operations

Opportunity Triggers

Trigger type Functionality
After Insert Connect opportunity to the active response - calculate first/last touch
After Update Update active response on opportunity close. Process reopened opportunities
Before Delete Disconnect and shut down attached active response before deletion
After insert and After update Queue up async custom funnel events if present

 

  • Was this article helpful?