Overview
Rules automate data manipulation on items. When an item is created, updated, deleted, or when a timer interval elapses, rules evaluate conditions and set field values automatically. They are the automation engine behind Ekso’s workflow capabilities — used to send notifications, update fields, create items, and drive integrations.
Rules do not prevent actions — they react to them. If you need to block an invalid action, use a constraint instead.
You manage rules under Settings > Rule. Each rule has three configuration tabs: Conditions, Actions, and Detail.
Creating a rule
The Detail tab configures the rule’s identity and trigger.
| Property | Description |
|---|
| Name | The rule name. Rules execute in alphabetical order, so use numeric prefixes to control sequence. |
| Description | Rich text description of what the rule does |
| Owner | Which part of the system owns the rule (e.g., System) |
| Container | Which containers the rule applies to (select All for tenant-wide) |
| Trigger | How the rule fires — Event or Timer |
| Event | When trigger is Event: which event fires the rule |
| Timer | When trigger is Timer: interval in minutes between evaluations |
| Deleted | Toggle to remove the rule from the system |
Name your rules with numeric prefixes to control execution order. For example, 01-set-priority, 02-assign-area, 03-notify. This makes the sequence explicit and easy to reorder.
Conditions
The Conditions tab defines when the rule fires. Each condition is a field–operator–value check (for example, Crm Equal Fenrise Inc or Severity Equal Minor).
Conditions are organized into groups:
- Within a group — conditions are combined with AND (all must match)
- Between groups — groups are combined with OR (any group can match)
This gives you flexible matching. For example: “fire this rule if the CRM is Fenrise Inc OR the Severity is Minor.”
Text fields support date tokens and arithmetic comparisons in their values (see Tokens below).
Actions
The Actions tab defines what happens when the rule fires. Each action selects a field and sets it to a value. A rule can have multiple actions — for example, set Priority to High and set Approved to true in a single rule.
Actions can update any field on the item, including fields that would normally be restricted by constraints. This is by design — rules act as a data manipulation escape hatch for automation.
Trigger types
Event triggers
Event rules fire when specific item lifecycle events occur.
| Event | When it fires |
|---|
| On Item Add | During item creation, before the item is saved. Allows data manipulation before the user sees the item. |
| On Item Added | After an item has been created and saved. |
| On Item Updated | After an item has been modified. |
| On Item Deleted | After an item has been deleted. |
On Item Add vs On Item Added: “Add” fires before save and can manipulate the item before the user sees it (setting defaults, auto-assigning fields). “Added” fires after save, when the item already exists in the system.
Timer triggers
Timer rules fire on a recurring interval rather than in response to a user action. You specify the interval in minutes (for example, every 10 minutes). Each time the timer fires, the rule evaluates its conditions against all matching items and applies actions to those that match.
Use timer rules for deadline-based automation — for example, checking whether a due date has passed and updating the status to Overdue, or sending reminder notifications.
Tokens
Rules support tokens that resolve to dynamic values at execution time. Use tokens in condition values and action values to set dates relative to the current moment.
| Token | Resolves to |
|---|
TODAY | Current date |
WEEK_START | Start of the current week |
WEEK_END | End of the current week |
MONTH_START | First day of the current month |
MONTH_END | Last day of the current month |
+n | n days after the reference date |
-n | n days before the reference date |
TODAY+7 means seven days from today. MONTH_END-1 means the day before the end of the current month.
Queued execution
The rule engine processes rules through a queue. Rules do not execute inline during the user’s action — they are queued and processed asynchronously.
Because rules execute asynchronously, changes may not appear instantly after item creation or update. The queue processes rules in order, and the effects will be applied shortly after the triggering action.
Rules and constraints
Rules bypass constraints. While constraints prevent users from setting invalid field values, rules can set any value regardless of constraint restrictions.
This separation is intentional:
- Constraints protect against user error and enforce data quality for manual actions
- Rules handle automated workflows where strict constraint enforcement would be counterproductive
For example, a rule might set a status that is normally blocked by a constraint, because the automated workflow requires it. The constraint still protects against users making the same change manually.
