Best Practices for Using Triggers
Updated
This article provides practical guidelines for admins and users who configure Triggers in Entity Studio that are easy to understand, predictable in behavior, and simple to maintain over time. These recommendations help you avoid unnecessary complexity, performance issues, and troubleshooting challenges.
1. Design triggers with one clear purpose
Each trigger should focus on a single job. This makes behavior easier to predict and simplifies troubleshooting.
Examples of clear, single-purpose triggers:
Product – Created – Validate required fields
Product – Updated – Log price changes
Order – Created or Updated – Recalculate totals
Customer – Scheduled – Mark inactive after 180 days without orders
If one trigger starts performing unrelated tasks—such as validation, external syncs, and logging—split it into separate triggers. Simpler triggers are easier to maintain and less likely to conflict with each other.
2. Use Pre‑Created for Validations and Post‑Created for Actions
A simple guideline:
Use pre‑created / pre‑updated for:
Validations
Mandatory checks
Logic that determines whether the record can be saved
These should always be fast and lightweight.
Use post‑created / post‑updated for:
Complex logic
Workflows, rules, and scripts
Logging or audit entries
Actions that rely on final, saved values
External calls or integrations
Example:
Pre‑created (Product):
Ensure required fields are filled. Block the save if a critical field is missing.Post‑updated (Product):
If the price changes, write an entry to the Price History entity.
3. Use synchronous runs only when necessary
Choose synchronous or asynchronous processing carefully:
Use synchronous when:
The record must not be saved if the action fails
You are enforcing critical consistency rules
Validation must be part of the save operation
Do not use Synchronous runs for running triggers on large number of records as it may lead to timeouts and load on the system.
Use asynchronous when:
The action is important but not required to complete before saving
You are sending data to external systems
Logging or analytics updates can run in the background
This keeps save operations fast while still allowing important work to happen.
4. Keep conditions simple and easy to read
When defining trigger conditions:
Use field names and values that align with how your business describes the scenario
Avoid deeply nested or overly complex conditions
Split very complex logic into multiple triggers when possible
Testing tip:
Always test conditions with:
One record that should pass
One record that should fail
One edge case
This ensures the trigger fires exactly where intended.
5. Document which fields each trigger modifies
Without documentation, two triggers may unintentionally overwrite each other's updates.
Keep simple notes—either in your internal documentation or as comments—describing what each trigger updates.
Example (Product entity):
Trigger A updates Inventory Status
Trigger B creates entries in Price History
Trigger C sets Synced to ERP
Documenting this prevents conflicts and makes future maintenance easier.
6. Avoid circular behavior and infinite loops
Be careful when configuring the triggers that update the same entity they are listening to.
Risk: A trigger on Product Updated that changes a Product field may cause the same trigger to fire repeatedly.
How to prevent loops:
Check whether a field actually changed before updating it
Use an indicator field (such as processed_by_trigger = true) to prevent repeated processing
Avoid updating a field unnecessarily (do not write the same value again)
These small checks prevent runaway logic.
7. Use scheduled triggers thoughtfully
Scheduled triggers run repeatedly, so use them carefully to avoid unnecessary background activity.
Best practices:
Use intervals that match real business needs—daily, weekly, or monthly rather than very frequent cycles
Use Occurrences to limit total runs
Use Exit Criteria to stop the schedule when no longer needed
Periodically review scheduled triggers to ensure they are still relevant
8. Use clear and descriptive names
Good names help new admins quickly understand how the system is designed.
Recommended naming pattern:
Entity – Event – Purpose
Examples:
Product – Created – Validate required fields
Product – Updated – Log price changes
Order – Created or Updated – Recalculate totals
Customer – Scheduled – Inactivity marker (180 days)
Apply the same clarity when naming:
Workflows
Rules
Scripts
Example:
Workflow – Order fulfillment
Rule – Product data quality
Script – Order risk scoring
9. Log important actions and errors
For triggers that do more than simple field updates, logging is essential.
Log items such as:
What action was taken
Key record details
Any errors
Where to log:
A history or audit entity
Notes or comments on the main record
External logging tools if your system supports them
Proper logging makes investigation and debugging easier.
10. Always test in a non‑production environment first
Before enabling triggers in production:
Configure the trigger in a sandbox.
Use sample Customers, Products, and Orders.
Test the following:
The trigger fires when expected
It does not fire when it should not
Performance is acceptable
Only enable the trigger in production after successful testing.