Triggers, or automation, in TargetX are executed when specific actions happen. For example, the TargetX Events tool includes a trigger that sends an email confirmation to a registrant immediately after he/she confirms a given event.
While most triggers run immediately or in the same execution as data saving, it is also possible to have a trigger run in a separate thread, also known as a future call or asynchronous processing.
In standard or synchronous trigger processing, all code is executed in the same thread or transaction. When many actions are processed simultaneously, all part of the same thread, you may find some operations are blocked for users while records are being processed or you may see issues related to governor or execution limits.
Using future methods or asynchronous processing, you can execute specific actions in a separate thread, thereby increasing governor and execution limits during processing.
By default, TargetX tools use synchronous triggers that execute in a single thread. There are some tools, though, that provide an option to run the trigger @future if desired. This change is made at the custom setting level. For more information, please see: Which TargetX tools support running triggers "at future"?
By default, TargetX tools use synchronous triggers that execute in a single thread. There are some tools, though, that provide an option to run the trigger @future if desired. Below is information on which TargetX tools include an option to run triggers asynchronously and why you may consider making this change.
The TargetX Application Requirements Manager tool supports the automated creation of application checklist items for applicants.
When an application record is created, a formula field evaluates the available data points on the record and determines an application type assignment. This value is then compared against your Application Requirement Rules and, if a match is found, the corresponding Application Requirements are created as individual Checklist Item records.
For most institutions, there is no need to run the Application Requirements Manager trigger using future calls. However, there are two reasons why you may choose to enable the @future setting for this trigger:
The Application Requirements Manager checklist item creation trigger can be changed to run @future by way of the RM Preferences Custom Setting.
The TargetX Source to Master tool allows you to roll up or mirror data from one detail or child object to the Contact record. Source to Master supports rolling data up to the Contact from the following objects: Enrollment History, Application, Test, and Inquiry.
When data is saved on one of the supported detail or child records (as noted above), the Source to Master trigger is executed. For objects where a roll-up has been configured, the trigger evaluates which data to roll up from which detail record and copies the data to the corresponding field on the contact record.
When using Source to Master, it is important to consider the fact that record saves are occurring on multiple objects during the same thread, or transaction in the CRM. For example, saving data to the Enrollment History will trigger the roll-up of that data to the Contact record, which will also cause a "save" transaction on the Contact record. When an institution is using Source to Master on multiple objects simultaneously, the risk of hitting governor and/or execution limits is increased. As a result, running the trigger @future may improve performance for institutions with a high level of automation.
The Source to Master trigger can be changed to run @future using the Base Custom Settings.
The TargetX Access Keys feature provides additional security when external users (e.g., applicants) are viewing data from the CRM on external pages such as the non-Communities based App Tracker. Each Contact is assigned a unique key value which is included in the URL when accessing pages, thereby preventing other users from modifying URL data to access another user's information.
When contact records are created through data import or manual entry, a unique key value is generated by the Access Keys trigger and stored on the contact record.
For most institutions, there is no need to run the Access Keys trigger using future calls. However, for institutions with a high number of custom automation (e.g. flows, process builder processes, roll-ups, and/or custom triggers), there may be value in running Access Keys @future to reduce the likelihood of hitting governor and execution limits.
The Access Keys trigger can be changed to run @future through the Base Custom Settings.
The Group Assignment triggers can be changed to run @future by way of the Group Assignment Custom Settings.
While enabling triggers to run @future on TargetX products may improve performance for some institutions, enabling the setting on all triggers is not advisable. If all triggers used future methods, the improvements to performance gained by executing some transactions asynchronously or in a second thread may be lost. This is because the total number of transactions in the second thread would be increased in a manner that may lead to you exceeding governor and/or execution limits in the second thread.