Automation
Workflow Rules
Rules that watch every maintenance ticket and act on your behalf — assigning, notifying, replying, and escalating without anyone clicking through the queue by hand.
A rule acts on real tickets and notifies real people the moment it is active. There is no rehearsal mode. The safest order is to read the order rules run in before you write a second rule — the interaction between two active rules is where the surprises live.
1The two kinds of rule
Every rule you build is either an event rule or a time rule. Nothing else exists underneath.
Go to Settings → Automation → Workflow Rules. Every rule in the list is one of two kinds:
| Kind | Fires when… |
|---|---|
| Event | Something just happened on a ticket — Fires the moment something happens on a ticket. |
| Time | A ticket has been sitting untouched for a while — When a ticket has been waiting this long. |
Event rules use New event rule and pick exactly one trigger — the builder itself says Pick exactly one trigger. The seven triggers are Ticket created, Tenant reply, Staff reply, Staff comment, Status changed, Assignee changed and Owner changed.
Time rules use New time rule and Pick one clock: Since the ticket was opened, Since the last staff reply, or Since the last tenant reply. Then a threshold — a whole number of hours or days, minimum one. Reset the clock when the ticket changes. is on by default, so ordinary ticket activity restarts the wait; turn it off to measure from the original timestamp regardless of later activity. A time rule either runs Once per ticket. or repeats on a Repeat every interval — How often it repeats. When you first save it, Apply to tickets that already match today. decides between Include the existing backlog and Only from now on — whether tickets that already match get caught, or only new activity does.
Conditions are identical between the two kinds. Up to ten fields — Subject or body contains, Category, Ticket type, Priority, Status, Property, Unit, Assigned to, Filed by, and Assigned to is unassigned — are all available on both. Every condition on a rule is ANDed together; all must be true. Subject or body contains matches if any one of several terms appears in either the subject or the body, case-insensitively. The other fields match if the ticket's value is any one of the values you picked. Assigned to is unassigned takes no value at all — it is true only when nobody is assigned. Leaving the list empty matches every ticket — the builder says so directly: Leave empty to match every ticket.
Actions run in a fixed order, whichever kind of rule you're building — that's why the copy in the time-rule builder is Same fields as an event rule and Same action set as event rules. There are six: Assign ticket, Send notification, Add internal comment, Auto reply to tenant, Change status, Change priority.
Add internal comment is staff-only. Auto reply to tenant is visible to the tenant. This is the footgun: pick the wrong action and either your team's private note lands in front of the renter, or a reply that was meant for the tenant never leaves your own screen. If a rule needs to set both the team and the person handling a ticket, use two separate Assign ticket actions — one action does one assignment.
2The order rules run in
The section people get wrong. Read this before your second rule.
Rules of one kind — Runs in the order listed — run in their listed order, top to bottom. The first rule that matches runs its actions, and then evaluation stops, unless that rule is set to Continue to the next matching rule. rather than Stop here.. The builder labels this choice plainly: After this rule runs, Controls chaining.
The case that trips people up is a broad rule sitting above a narrow one. Say you have an org-wide rule — any urgent maintenance ticket goes to the on-call queue — and a narrower rule for one specific property, where urgent maintenance should instead go to that property's own manager. If the broad, org-wide rule sits first in the list, it matches every urgent ticket, including the ones at that property, and (left on Stop here.) stops evaluation right there. The property-specific rule never gets a turn, no matter how correctly its conditions are written.
The fix is reordering, not rewriting conditions. Put the narrow, property-specific rule above the broad, org-wide one. Now the narrow rule gets first look at every ticket; it matches and handles the tickets it's meant for, and everything else falls through to the broad rule below it.
The list screen catches this for you: a rule that can never win shows Never runs -- an earlier rule always matches first right on its row. If you see that, the fix is always to move the flagged rule up, not to add more conditions to it.
3Building an escalation ladder
There is no escalation feature. There are just time rules with increasing thresholds on the same clock.
Return Grid has nothing called an "escalation ladder" in the product — it's deliberately not a special object. An escalation ladder is two or three ordinary time rules, all reading the same clock, with increasing thresholds. For example:
- At 24 hours, notify the assigned person.
- At 48 hours, notify the owning team.
- At 72 hours, raise the priority.
Each of those is an ordinary time rule you build with New time rule, picking the same option under Pick one clock for all three, and a different threshold on each. List them in threshold order, lowest first, and leave every rung on Stop here.. The ladder works because the thresholds differ, not because of anything special about how the rules are built.
Set every rung to Once per ticket. — that is the part that makes a ladder a ladder. Time rules are checked in their listed order and the first rule that is due wins and stops, exactly like event rules. A rung that has already fired for a ticket is no longer due for it, so it drops out of the running and the next sweep lets the rung below it have its turn. That is how a ticket climbs: the 24-hour rung fires once and steps aside, so at 48 hours the second rung is the first one still due, and at 72 hours the third.
Do not give a low rung a Repeat every interval and expect the higher rungs to still fire. A repeating rung becomes due again and again, and because it sits above the others it wins every time — so the 48-hour and 72-hour rungs never run at all. This failure is quiet in the product but obvious in the rule log: the higher rungs appear there as Skipped, never as Applied. If you want one rung to nag repeatedly, make it the last one in the list.
Reset the clock when the ticket changes. is on by default and does something narrower than it sounds. With Once per ticket., "once" means once per episode rather than once ever: if a ticket goes quiet, gets chased by the rung, then sees real activity and afterwards goes quiet again for the whole threshold, that is a genuinely new occurrence and the rung fires again. Turn it off if you want a rung to notify strictly one time and never again, whatever happens to the ticket afterwards.
Pick the clock to match what you are chasing, or the ladder will never fire at all. A rule can only measure from a timestamp the ticket actually has. If you build a "nobody has replied yet" ladder on Since the last staff reply, it can never fire on the very tickets you meant to catch — a ticket nobody has replied to has no last-staff-reply timestamp to measure from, so the rule quietly passes over it forever. Use Since the ticket was opened for chasing a first response, and reach for Since the last staff reply only for chasing a conversation that has already started.
One more setting matters when you add a ladder to a queue that already has old tickets in it. A rung set to Only from now on permanently ignores tickets that were already past its threshold at the moment you switched the rule on, so turning on a 72-hour rung does not immediately fire at every stale ticket in the backlog at once. That exclusion is measured from when the rule was activated, so re-enabling a paused rule measures from when it came back, not from when it was first created.
Finally, time rules never chase finished work: a ticket in a closed or resolved status is passed over regardless of how long its clock has been running, so a ladder cannot nag anyone about a ticket that is already done.
4Owned by, versus Assigned to
Two independent fields on a ticket. Confusing them is the second most common mistake, after the order one.
Every ticket carries two separate fields, both labelled with an em dash on the ticket panel: Owned by — team and Assigned to — person. A ticket can have neither, either, or both, and one can change independently of the other.
| Field | What it answers |
|---|---|
| Owned by — team | Who is accountable for this ticket. |
| Assigned to — person | Who is actually doing the work right now. |
Both fields exist so a ticket can stay owned by a team while it moves between the individual people on that team, and so a rule can route work to a team without having to name a specific human at rule-writing time. A rule's Assign ticket action can set either field, or both — use two separate Assign ticket actions on the same rule if you want to set the team and the person together, since each action sets one target.
5Reading the rule log
Every rule's decision, kept for 90 days, one row at a time.
From Settings → Automation → Workflow Rules, use the Rule log button, or View log for this rule from an individual rule's row to jump in pre-filtered to just that one. The columns are When, Rule, Kind, Ticket, Outcome, and What it did.
Filters across the top: Rule: All, Property: All, Outcome: All, and a date window that defaults to Last 7 days, with Last 30 days, Last 90 days and Custom… also on offer. An Export CSV button sits alongside them. Entries are kept for 90 days.
| Outcome | What it means |
|---|---|
| Applied | The rule matched, and its actions ran. |
| Skipped | The rule matched — but an earlier rule had already matched and stopped evaluation, so this rule's actions did not run. |
| Failed | The rule matched and was allowed to run, but an action did not complete. |
A Skipped row is not an error. It's the first-match-wins behaviour from the order rules run in being recorded honestly — the rule genuinely matched, it just lost to a rule above it. This is the row support will ask about most. Repeated Skipped rows on a rule you expect to be doing real work is the signal that it's sitting too low in the list; move it up rather than editing its conditions.
A rule that simply never matched a ticket produces no row at all. An empty log for a rule means it never matched anything in the window you're looking at — not that it was blocked or suppressed.
Time rules run near their threshold, not to the minute. They're evaluated by a periodic sweep, so a rule set to fire at 24 hours actually fires on the first sweep after the 24-hour mark passes, not at the exact stroke of 24 hours. Return Grid doesn't publish or guarantee how often that sweep runs. To see where a given rule actually stands, open it in the builder and read its own header — it reports Checked periodically followed by when it was last checked.
Before you write a rule you're unsure about, use Preview before you save in the builder — Check how many tickets match shows you how many existing tickets your conditions would catch, before anything actually fires.
6What v1 cannot do
Four honest limits, so you don't design around a capability that isn't there.
- No OR conditions. Every condition on a rule is ANDed together. If you need "this OR that," write two separate rules instead of trying to express the alternative inside one.
- No business hours. A time rule counts plain elapsed wall-clock time. A threshold set over a weekend or a holiday keeps counting the whole way through — there is no working-hours calendar to pause it.
- No round-robin. Assign ticket targets one named person or one named team, chosen when you build the rule. There is no rotation, no load balancing, and no next-in-line logic.
- Not to-the-minute. Time rules are checked by a periodic sweep, so they fire near their threshold rather than at the exact instant it's crossed. Return Grid doesn't publish a cadence for that sweep — check the rule's own Checked periodically line in the builder rather than assuming a fixed schedule.
Worth knowing but not one of the four above: a chain of rules that trigger each other — one rule's action changing a ticket in a way that satisfies another rule's trigger — is depth-capped so it can't run away, and a rule can never retrigger itself.