Configuring Triggers
Updated
This article is a product configuration guide. It walks step‑by‑step through the trigger configuration interface and explains what each field does, using simple examples.
Accessing Triggers in Entity Studio :
Access Entity Manager from the Entity Studio tab.
Click Standard or Custom on the Entity Manager page, and the list of entities will appear.
Search for the desired entity in the search bar among the entities and click the View button next to the Entity name.
Click on Triggers from the left pane and click on Create New Trigger available on the rop right.
You will see a configuration screen divided into the following key sections:
1. Basic details
At the top of the trigger configuration, you usually set:
1.1 Trigger Name
A short, descriptive name. Good examples:
Product – On Create – Validate Fields
Product – On Update – Log Price Changes
Order – On Create/Update – Recalculate Totals
The key is that other admins should understand what the trigger is for just by reading this.
1.2 Description
A longer explanation of what the trigger does and why it exists.
Example:
“Ensures that new products always have a name, SKU, and inventory status. Blocks creation if any of these are missing.”
1.3 Entity
The entity this trigger is attached to (for example, Product, Customer, Order).
Based on the entity on which you are creating the trigger, that entity will be selected and locked.
2. Selecting the Trigger Event
This section is usually labeled Trigger Event and shows radio buttons or options like:
Created
Updated
Created or Updated
Deleted
Choose one based on when you want the trigger to run.
2.1 Created
Use this when you want actions only at the first creation of a record.
Example:
Product, Created:
Set default Inventory Status to Active if empty.
Check that required fields are valid.
2.2 Updated
Use this when you only care about changes to existing records.
Example:
Order, Updated:
When Status changes to Cancelled, update related flags and fields.
2.3 Created or Updated
Use this when you want a single trigger to cover both creation and updates.
Example:
Order, Created or Updated:
Always recalculate Total Amount from the current line items and discounts.
2.4 Deleted
Use this when you need to react when a record is deleted.
Example:
Order, Deleted:
Create an audit log entry recording who deleted the order and when.
3. Order of Action Execution
The Execution Timing section controls whether the trigger runs before or after the database operation.
Depending on the chosen Trigger Event, you see different options. Typical combinations:
Event: Created → Timing: Pre‑Created or Post‑Created
Event: Updated → Timing: Pre‑Updated or Post‑Updated
Event: Created or Updated → Timing: Pre‑Created or Post‑Updated (hybrid)
3.1 Pre‑Created
Runs before a new record is saved.
Used for validations and quick checks.
Can block the save if the action fails (especially for Synchronous triggers).
Example use:
On Product creation:
Check that Product Name and SKU are not empty.
Check that Retail Price is not less than Unit Cost.
If any check fails, show an error and do not save the product.
3.2 Post‑Created
Runs after a new record is saved.
Has full access to all field values.
Cannot block the fact that the record already exists, but can still perform further actions.
Example use:
On Customer creation:
Use all customer data to create a corresponding account in an external billing system.
Store the external ID back on the Customer record.
3.3 Pre‑Updated
Runs before the update of an existing record is committed.
Used to prevent invalid changes.
Example use:
On Order update:
If the new Status is Delivered but no Shipment Tracking Number is set, block the update.
3.4 Post‑Updated
Runs after an existing record has been updated.
Can access both old and new values of fields.
Example use:
On Product update:
If Retail Price changed, create a Price History entry recording Old Price and New Price.
3.5 Pre‑Created or Post‑Updated (hybrid)
When Trigger Event is Created or Updated, you may see a combined option:
“Pre‑Created or Post‑Updated.”
This means:
On creation: the trigger runs at Pre‑Created time.
On update: the trigger runs at Post‑Updated time.
This is useful when you want:
Fast validation before creating records, and
Rich post‑update behaviour (like comparisons) for later changes.
4. Data Sync Type
The Data Sync Type section is only available when the selected Order of Execution is of Post type i.e. Post Created, Post Updated etc.
Data Sync type consists of two options :
Synchronous (wait for completion)
Asynchronous (fire and forget)
This setting determines how tightly the trigger’s action is tied to the record save.
4.1 Synchronous (wait for completion)
The trigger action is part of the save transaction.
The user waits until the action finishes.
If the action fails, the save fails.
When to use:
When you must be sure certain logic is applied before accepting the change.
Examples:
When creating an Order, make a check against stock availability in another system; if the check fails, do not create the Order.
When marking a Payment as Completed, verify with an external gateway; if verification fails, do not mark as Completed.
4.2 Asynchronous (fire and forget)
The record is saved first.
The trigger action runs after, in the background.
The user gets a success response quickly.
If the action fails, the record still exists and must be handled separately (for example, via logs or retries).
When to use:
When the action is important but not critical for the record to exist.
Examples:
After an Order is saved, send its data to a reporting or analytics system.
After a Product is updated, push updated fields to a search index.
5. Conditions (Filters)
The Conditions section lets you restrict when the trigger should run. It usually has:
A button to Add Filter or Add Condition.
Per‑condition controls for:
Field
Operator
Value
Options to group conditions (AND / OR).
5.1 Adding a single condition
Example setup for an Order trigger:
Field: Status
Operator: Equals
Value: Confirmed
Result: this trigger only runs when the Order’s Status is Confirmed.
5.2 Multiple conditions with AND
Example:
Condition 1: Status Equals Confirmed
Condition 2: Total Amount Greater or equal 10000
Result: the trigger runs only when both conditions are true. In other words, only for high‑value confirmed orders.
5.3 Using groups (AND / OR logic)
The condition builder usually allows you to:
Group conditions together.
Choose whether conditions inside a group use AND or OR.
Combine groups with AND or OR.
Example requirement in plain language:
“Run when the product is important and something about its pricing changed.”
Configuration:
Group 1 – Important Product:
Retail Price Greater or equal 5000
OR Category Equals Premium
Group 2 – Pricing Change:
Retail Price changed
Overall logic: Group 1 AND Group 2.
This means:
Only products that are important and have a changed price will trigger this automation.
5.4 Condition management
These options are available under three dots next to the condition defined helping you to build and maintain complex logic in a readable way.
Duplicate condition: copy it to create a similar one quickly.
Clear or Delete condition: remove it.
Turn into Group: convert a single condition into a group container so you can add more OR/AND entries under it.
6. Schedule Trigger
The Schedule Trigger toggle exposes options to run the trigger not just once, but repeatedly, on a time schedule.
When you enable Schedule Trigger, you typically see:
Run Trigger Every
Number (for example, 2, 5, 30)
Unit (Hours, Days, Weeks, Months)
Occurrences
How many times to repeat. Blank usually means “no limit”.
Exit Criteria (optional)
Conditions that, when true, stop the schedule for that record.
6.1 Run Trigger Every
Examples:
Every 1 day → run once a day.
Every 7 days → run once a week.
Every 30 days → run once a month.
Use cases:
Daily review of Orders that are Pending Payment.
Weekly review of Products marked Discontinued.
Monthly review of Customers who have not ordered.
6.2 Occurrences
Examples:
5 → run a total of 5 times then stop.
Blank → run indefinitely, until Exit Criteria matches or the record is deleted.
Example use:
“Run every 1 day, 5 occurrences” could send or trigger up to five follow‑ups, and then stop.
6.3 Exit Criteria
Exit Criteria are conditions similar to normal trigger conditions, but they are used to stop the schedule.
Example:
Exit Criteria: Status Not Equals Pending Payment.
If you schedule a trigger to run every day for Orders with Status = Pending Payment, Exit Criteria ensure that:
As soon as Status changes to something else (for example, Confirmed or Cancelled), the scheduler stops running for that order.
7. Action Type
At the bottom of the trigger configuration, you choose an Action Type. The options are typically:
Run Workflow
Run Rule
Run Script
After choosing one, you select a specific Workflow, Rule, or Script from a drop‑down of items you have already created.
7.1 Run Workflow
Use Run Workflow when you want to execute a multi‑step workflow you have built in the Guided Workflow.
Examples:
“Order Fulfilment” workflow:
Reserve stock.
Create shipment.
Update statuses.
Write logs.
“Product Sync to ERP” workflow:
Prepare payload.
Call ERP API.
Handle success or failure.
7.2 Run Rule
Use Run Rule when you want to apply a set of validations or simple business logic defined in the Rule Engine. Note that limited support is available for Run Rule via Rule Engine.
7.3 Run Script
Use Run Script when you need to execute custom code for advanced or custom scenarios.
Examples:
“Order Risk Scoring” script:
Calculate a risk score based on multiple fields.
Set risk level fields on the record.
“Product Matching” script:
Compare the product with existing records to detect potential duplicates using custom logic.
The script logic is written and maintained in the Script editor. The trigger simply calls it when its own conditions are met.
8. Enable Triggers
After the trigger is configured, click on Save. You will be navigated to the Triggers page where the list of triggers are displayed. Enable the Trigger using the toggle next to the trigger name.
Toggle ON/OFF control.
When Enabled: the trigger participates in automation.
When Disabled: the trigger is ignored, even if all other settings are correct.
You can temporarily disable a trigger during testing or while making changes.