Triggers let you automate actions when changes are made to the records of an entity. They help you maintain data quality, reduce manual work, and keep business workflows consistent. A trigger can validate data, update related records, or run automation such as a workflow, rule, or script. This article explains what triggers are, why they are useful, and how they work at a high level.

Triggers in Entity Studio

A trigger is an automation that runs when a record is created, updated, or deleted. The platform watches for events on an entity and automatically runs an action when the trigger’s criteria are met.

​

Every trigger follows the same structure:

“When this event happens on this entity, if these conditions are met, then run this action automatically.”

• Event

  — What happened to the record (Examples: a Product was created, an Order was deleted).

• Conditions

  — Which records the trigger applies to (Examples: Only active Products, Only Products with Category = Electronics, only Orders with Total Amount > 500).

• Action

  — What should happen (Examples: Run a workflow, run a rule, run a script).

Once a trigger is activated, it runs automatically, users do not need to click anything. The platform automatically evaluates records whenever the configured event and conditions match.

Where Are Triggers Used?

Triggers are configured for each entity. You can create triggers on the following:

• Standard entities (Customer, Product, Order, etc.)

• Any Custom Entities you define

  ​

Examples:

Product

• Ensure required fields like Product Name and Category are filled.

• Sync product data to a third-party system.

• Alert users when the stock quantity falls below a threshold.

Order

• Recalculate totals when line items change.

• Update status when an order is canceled.

• Flag orders that remain in “Pending Payment” for too long.

Customer

• Set default values when a customer is created.

• Mark customers as inactive if they have not purchased recently.

Trigger Event Types

When you create a trigger, choose when it should run. The platform supports four event types:

​

1. Created

Runs when a new record is added.

Example: When a Product is created, set the default Status to "Available".

​

2. Updated

Runs when an existing record is modified.

Example: When an Order’s Status changes to "Cancelled", update related fields.

​

3. Created or Updated

Runs both when the record is created and when it is later modified.

Example: Whenever an Order is created or updated, recalculate Total Amount.

​

4. Deleted

Runs when a record is deleted.

Example: When an Order is deleted, create an audit record with details of the deletion.

​

These four types cover the entire lifecycle of a record—new, changed, and removed.

Order of Action Execution: Before or After Save

Each Trigger Event can be combined with an Execution Timing. This controls when the trigger runs relative to the database save. You can configure a trigger to run before or after the record is saved.

​

Pre‑Created / Pre‑Updated

Runs before the record is saved.

Best for:

• Validations

• Preventing invalid or incomplete data

Example: Before a Product is created, check that Product Name and Category are filled.

​

Post‑Created / Post‑Updated

Runs after the record is saved.

Best for:

• Creating logs

• Syncing data

• Running side-effect actions

Example: After a Product’s Price changes, log both the old and new values in a Price History entity.

​

Hybrid Timing Combinations

You may also combine timings. When using Created or Updated, the trigger can be mixed:

• Pre‑Created or Pre‑Updated

• Pre‑Created or Post‑Updated

• Post‑Created or Pre‑Updated

• Post‑Created or Post‑Updated

These are useful when you want fast validation at creation and more complex logic on updates.

Data Sync Type: Synchronous vs Asynchronous

Each trigger has a Data Sync Type conditional settings which is reflected when order of execution action is selected as Post type. When the timing includes any Post option, you can choose how the trigger runs.

​

Synchronous (wait for completion)

• The trigger action and database update happen together.

• The user waits until the action finishes.

• If the action fails, the record is not saved.

Use when the action determines whether the record is valid.

​

Asynchronous (run in background)

• The record saves immediately.

• The trigger action runs in the background.

• If the action fails, the record remains saved.

Use when the action is a side effect (e.g., sending data to analytics).

Conditions: Which Records The Trigger Applies To

Triggers have conditions (filters) that decide which records the trigger applies to. Without conditions, a trigger would run for every record on the chosen event, which is usually not desired. Conditions filter when the trigger should run.

Each condition includes:

• Field (example - Order Status, Total Amount, Product Category).

• Operator (Equals, Does Not Equal, Contains, Greater Than, Less Than, Is Empty, Is Not Empty, etc.).

• Value (example - “Confirmed”, 10000, “Electronics”).

You can add multiple conditions and group them with AND / OR logic.

Example:

• Entity: Order

• Condition 1: Equals (Status = Confirmed)

• Condition 2: Greater or equal (Total Amount ≥ 10,000)

Result: The trigger runs only for orders that are both Confirmed and worth at least 10,000.

Schedule Triggers: Delayed and Recurring Runs

The Schedule Trigger toggle allows triggers to run not just once, but repeatedly, based on time.

When Schedule Trigger is enabled, you can:

• Run the trigger every X hours, days, weeks, or months.

• Limit the number of Occurrences

• Use Exit Criteria that stop the schedule when a condition is met.

Example:

“After a customer is created, check every 6 months whether they have placed an order. If they still have no orders, mark Customer Status = Inactive and stop the schedule.”

Trigger Actions: what happens when triggers fire

After conditions are met, a trigger must perform an action. You can choose one of the following:

1. Run Workflow
   Execute a pre‑created Guided Workflow.

2. Run Rule
   Execute a pre‑created Rule from Rule Engine.

3. Run Script
   Execute custom code for advanced scenarios.

The trigger configuration selects which of these to use and then points to a specific Workflow, Rule, or Script you configured elsewhere.

This separation keeps trigger configuration focused on when and for whom, while Workflows/Rules/Scripts handle what exactly to do.