Delayed and recursive triggers

If you would like a trigger to be delayed relative to a particular date and time, you can specify delay criteria.

Trigger Delay Time

A trigger can be delayed relative to the current time or relative to the value of any date or date/time field for the selected record.

Use the following parameters to specify the delay criteria for a trigger.

• Run as Large job: Check this option to run the delayed trigger as a large job. This enables the trigger run to be queued up as large job with additional monitoring and cancellation support. Matured large trigger jobs are served sequentially be separate thread pool

   Note:

  • It is not recommended to use this option for small-sized triggers written with simple computations .

  • Large trigger runs the script in an unbounded environment. However, the script execution will not stop pre-emptively due to max js time exceeding. This may cause the script to run in an infinite loop, blocking the other trigger runs.

  • The default pool size for a Large Event Executor Service is 1. This can be increased until 30 threads by the instance administrator using the DelayedTriggersExecutorThreadCount shared property.

  • Large job honors delayed and recursive settings, if specified. If no delay timings are set, the trigger is queued as a large job to be picked up and run immediately by separate thread.

• Run Relative To: Select this to delay the trigger relatively to a particular date/time field type rather than run immediately.

• Run At: Specify the delay duration here.

  Note: For delayed triggers, the options "Before" or "After" usually do not make any difference.

The following example shows a trigger that will run twenty days after the last record's update.

Recursion

You can also specify criteria to run a particular trigger periodically, including the maximum number of times to run. The example below shows a trigger that runs every week starting from the last record's update, up to 3 times.

You can view stored delayed triggers by clicking Queue on an object view page. A queue displays up to 1000 stored triggers and shows when they will run. It can be filtered by the selected object record.

When setting triggers to run after a delay or repeat, keep the following in mind:

• Be careful when using delayed or repeated triggers to avoid unnecessary recursion.
• For delayed triggers, the timing options before or after update or creation are irrelevant.
• Object Script running in delayed or recursive triggers uses the Server API role to calculate permissions. For information about permissions, see Access control.
• Delayed and recursive triggers do not run if a customer tenant is expired or inactive.
• Recursive triggers are not supported for the Before Delete and After Delete timing options, because the record is already deleted before the second attempt at firing the trigger.
• The Debug Formula button in the trigger formula editor for delayed or recursive triggers uses the Server API role to calculate permissions.
• If a Date field is used as relative point for a delayed trigger, its value is interpreted as 12:00 am. in the user's time zone. If a Date or Date/Time field has no value, no delay will be set and the trigger will run immediately.
• Before queuing any delayed or recursive triggers, the on Field Change check is performed.
  • If the above evaluation returns true, delayed or recursive trigger is added to the queue.
  • If the above evaluation returns false, delayed or recursive trigger is not added to the queue.
• Likewise, before queuing any delayed or recursive triggers, the Conditional Formula evaluation is not performed. This action is performed only when any delayed or recursive trigger in a queue gets matured (after delay time set on the trigger).
  • If the above evaluation returns true, the delayed or recursive trigger gets executed.
  • If the above evaluation returns false, the delayed or recursive trigger does not get executed.

See Debugging delayed triggers for more on debugging delayed triggers.