Trigger overview

Triggers can perform automated validation, notification, and data manipulation. You can configure triggers to fire upon events such as record creation, update, and deletion, as a result of a workflow flow action, and you can run triggers manually.

The triggers available for an object depend on that object's properties and components. For example, some triggers are only available when object attributes such as Workflow or Audit Trail are enabled. Others depend on components that you must create first, such as a conversion map or template. The timing options available also depend on the type of trigger you are creating.

A trigger is associated with an object definition. You can view or create new triggers from the Triggers component table. Depending on the type of trigger, its formula can calculate and set values or specify a condition that causes the trigger to fire.

To conditionalize a trigger, specify a formula that returns a boolean value. If the value evaluates to false or null for a particular record, the trigger will not run on that record.

For example, to run triggers only for large orders, you could use a formula such as:

{!amount} > 10000

A single line of JavaScript such as that shown above that evaluates to true, false, or null does not require a return statement. However, multi-line conditions such as those shown in other examples do require a return statement.

When defining a trigger you can also specify:

• Whether or not the trigger is deployed. Undeployed triggers will not run.
• An integration name, which is good practice and allows you to invoke the trigger using the rbv_api.runTrigger() method.
• Whether to run a trigger only when a particular field has changed its value (this will only affect After Update triggers). You can use template and formula fields in this condition, allowing you to determine whether or not the trigger should fire based on changes to a group of fields instead of a single field.
• If a trigger updates an existing record or creates a new record, you can specify whether dependent triggers (before/after update, before/after create) should also run. Use this option with caution, since it may lead to inefficient nested trigger invocations.

Built-in triggers provide the following capabilities, which are described further in the linked content:

• Send Email
• Create Audit Trail Record
• Validate Record Data
• Unique Fields Combination
• Update Field Value
• Change Workflow Status
• Create New Record
• Attach Related Record
• Create Template Document
• Run Triggers on Related Records
• Object Script
• HTTP triggers Send GET, POST, or SMS messages

The graphic below illustrates the general order in which Platform runs triggers when you specify a timing option. See Trigger timing options for more details.