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 → 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.
Important Dates rules can wait for a time of day. On an Important Dates time rule, at sets the hour the rule waits for, in your organization’s time zone. Leave it on Any time and the rule sends on the first hourly check after it comes due, as before. Pick an hour, such as 8:00 AM, and the rule counts calendar days and sends once your organization’s clock reaches that hour. Choosing an hour also lets the days box be 0, which means “on the day”: a rule set to 0 days at 8:00 AM sends at 8 AM on the event date. A rule with no hour still needs at least 1 day.
A system past its expected life opens a task. Every organization starts with an Important Dates time rule named System past its expected life. The date it watches is the system’s install date plus its expected life in years, so a system with only an install year is skipped. The day after that date, the rule creates one task for the property’s property managers, naming the system, unit and property. The task is linked to the system: Open system takes you to its record, and Create job starts a new job on the property for that system. Close the task to say the system stays in service; it is not created again. A system that was already past its life before the rule existed gets no task. The rule can be edited, switched off or given other recipients like any other time rule.
A showing start sends a push to the people hosting it. Every organization starts with an Important Dates time rule named Showing starting soon. It watches the start time of each rental showing, read as your organization’s local time, and one hour before it sends a push notification to the people hosting that showing. It is sent once per showing; if the showing is moved to another time, it is sent again for the new time. A cancelled showing sends nothing. Change the number of hours (1 to 72) in the unit picker, switch the rule off, or add other recipients like any other time rule.
A booked repair visit sends the evening-before reminder. Every organization starts with an Important Dates time rule named Repair visit tomorrow: one day before the visit, at 5 PM your organization’s time. It tells the people on the maintenance request, once per visit, and lists every window when a tenant has two visits that day. A visit that is cancelled, finished, moved, or where the tenant asked for a new time, sends nothing for the old window. A visit booked or moved with less notice than the short-notice cutoff in Maintenance Defaults is skipped. Change the hour, switch the rule off, or edit the wording like any other time rule.
The renter’s maintenance emails are request rules. Every organization starts with two ticket event rules that email the tenant who filed a maintenance request. Tell the tenant their request was received runs on Ticket created, and Tell the tenant when the status changes runs on Status changed. Each has one Send notification action to The tenant who filed the request. The wording is the message template, Your maintenance request was received or Your maintenance request changed status, edited under Message templates, so the rule has no subject or body of its own. Turn a rule off and renters stop getting that email. Nothing is sent when the request has no tenant on it, for a Messages thread such as a dispute or a renewal offer, or for a request the system opens on its own. A reply you write to a renter is not a rule and is always sent. Only a rule on Ticket created or Status changed offers this recipient.
Repair visit notices are three rules. On a Repair Items rule, A visit is booked, A visit is moved and A visit is cancelled run when staff save the visit window on a job that belongs to a maintenance request. Every organization starts with one rule for each, named Tell the tenant their repair visit was booked, moved or cancelled, sent to The people on the request: the renter on the request, anyone added to it, and the other renters on the lease. Each person is told by email, and by text when they have a verified number and allow texts, plus a notice in the Tenant Portal. Each renter’s own settings decide which of those they receive. The wording is the matching message template (A repair visit was scheduled, A repair visit time changed, A repair visit is no longer scheduled), edited under Settings, Message templates, so these rules do not take custom subject or body text. The Tell the tenant box on the job still skips the notice for one save. Switch a rule off or delete it and that notice is no longer sent.
Invite renters to the Tenant Portal on a schedule. Every organization has a Rent ledger rule named Invite renters to the Tenant Portal, switched on from the start; switch it off if you invite renters yourself. While it is on, each time a charge is added to a lease (monthly rent included) every renter on that lease with an email on file, no working portal login and no open invite is sent the Tenant Portal invite, which is good for the number of days set under Tenant Portal Branding → How long an invite is good for (7 by default, from 1 to 30). A renter whose invite has expired is invited again at the next charge, and nobody is invited twice while an invite is still open. The wording is the Tenant Portal invite message template, edited under Settings → Message templates. A renter who has not used the invite gets one reminder, with a new link for the same expiry date (the earlier link stops working), after the number of days in Remind after (days) on the rule (3 by default; leave it empty for no reminder, or switch the rule off to stop both). The reminder wording is the Tenant portal invite reminder message template. Each run appears under History.
Security deposit notices are three Lease rules. On a Lease rule, A deposit notice of claim is posted, A deposit return letter is posted and A deposit dispute is resolved run the moment you post the notice of claim, record the return, or resolve the dispute from the lease. Every organization starts with one rule for each, sent to The renters on the lease: every renter on the lease who has an email address is told by email with the letter attached. A renter with a Tenant Portal account is also texted when they have a verified number and allow texts, and gets a notice in the Portal; a renter who was never invited to the Portal is invited at the same time: the letter goes first, then the usual Portal invite email, so the renter can sign in and find the letter on the Security Deposits page. If your Tenant Portal is switched off, that renter gets the letter by email only. The wording is the matching deposit message template, edited under Settings, Message templates, so these rules take no custom subject or body text. Switch a rule off, or delete it, if you deliver that letter another way. The editor shows a warning at the top for that reason: with the rule off, Return Grid sends the renters nothing when you post the notice. The lease still records the notice and the deadline still runs, and the letter is still shown to the renters on their Security Deposits page in the Tenant Portal. After you post, a message tells you if the renters were not emailed because the rule was off, or because no renter on the lease has an email address on file. The Email the tenant this letter box on the return step still skips the notice for that one return.
Automatic rent payment results are two more Lease rules. An automatic rent payment goes through and An automatic rent payment does not go through run after each automatic debit. Every organization starts with one rule for each, sent to The renter who set up automatic payments, by email, text and a notice in the Tenant Portal. The wording is unchanged: the receipt, and the failed-payment message that says Return Grid will not try again this month. A renter who muted payment reminders is still told when a payment fails. These rules take no custom subject or body text. Switch one off, or delete it, only if you tell renters another way: the editor warns that the renter would not be told, and would have to be collected another way if a payment fails. The payment itself and your own failed-payment alert are not affected.
Three more renter emails are rules. A Lease rule on A lease signature request is withdrawn runs when you void a signature request on a lease, and tells The renters asked to sign why it was withdrawn, with your note if you wrote one. An Application rule on Application submitted can tell The applicant that their application was received. A third Lease rule, An intake form is submitted, tells The renter who filled in the form that their intake form was received (it is sent only when the renter typed an email on the form; the notification to your own staff on the form’s notify list is not a rule). Every organization starts with one rule for each of these, and they go ahead of your other rules so no earlier rule can stop them. Both are email only, the wording is the matching message template (The lease signature request was withdrawn, Application submitted confirmation, Intake form submission received), and neither takes custom subject or body text. Switch a rule off, or delete it, only if you tell people another way: the editor warns about it. With the signature rule off, the renters only get the e-signature provider’s own recall notice, which gives no reason, and the confirmation shown after you void says the renters were not told. With the application rule off, the applicant gets no confirmation and may submit again. With the intake rule off, the renter gets no confirmation and may fill the form in again.
Tax form requests have their own event rule. Choose Tax Forms when you start a new rule to act when a renter asks for a tax form, such as the Wisconsin Rent Certificate, in the Tenant Portal. Its one trigger is Renter requested a tax form. The only condition is Property. The actions are Send notification and Send push notification, sent to the property manager, a specific user or a specific team, and Create a task. A task is due a number of days after the request (7 unless you change it, up to 60) and is titled like “Prepare 2025 Wisconsin Rent Certificate for Jane Renter” unless you give it your own title. It is on the renter’s lease, assigned to the property’s managers, and its Open tax form button opens that renter on Leasing → People → Tax forms. Each request makes one task, even if more than one rule creates tasks or the task is already closed. Every account starts with one, Tenant tax form requested, which emails the property managers with a link to that renter on Leasing → People → Tax forms. A property with no property manager notifies no one, but the request still shows as Requested there.
Insurance agency responses have their own event rule. Choose Insurance requests when you start a new rule to act when an insurance agency sends a certificate, a policy number or a quote through the link you emailed it. Its one trigger is An insurance agency sent something back. The only condition is Property. The actions are Send notification and Send push notification, sent to Whoever sent the request, the property manager, a specific user or a specific team. Every account starts with one, Insurance agency responded, which emails whoever sent the request and the property managers. A person who is both gets one email, not two. Each time an agency sends something the rule runs once, so an agency that sends several files in a row can cause several emails. The email links to the Insurance policies page, or for a quote to the property’s Renewals & Expenses tab.
A stale property value has its own event rule. Choose Valuation when you start a new rule to act when a property you own has a current market value that is over 12 months old, or was never set 90 days after you bought it. Its one trigger is A property’s value is over 12 months old (or never set). The only condition is Property, and the actions are Create a task, Send notification and Send push notification. A notification goes to the property managers, a specific user or a specific team, and links to the property. For Create a task, set how many days it is due in (0 to 60), its priority, and who it is assigned to — the property’s managers, a specific person or a specific team. Every account starts with one, Stale valuation: task for the property manager, which creates a low-priority task for the property managers, due in 14 days. A property only ever has one open valuation task. Before the rule runs, Return Grid asks RentCast for its estimate of the property’s value; when it gets one, the task title shows it and the task gets a Review button on Tasks Due. Review shows the estimate beside the recorded value, with Use this value and Dismiss. Using it records the figure with the source RentCast and dates it the day it was fetched; an appraisal you enter yourself is never replaced automatically. The property’s Current market value panel shows the same estimate and a Value history table of everything recorded.
New applications notify the organization owner by default. Every organization starts with two Application rules that run when an application is submitted, and both send an email and a push notification to The organization owner. Application for a unit: notify the owner runs when the applicant applied for a specific unit; edit it to notify The property manager of that unit instead. General application (no unit): notify the owner runs when the application is not tied to a unit; a general application has no property manager, so edit it to notify the person or team you choose. The split uses the Applied for condition, which is either A specific unit or No unit (general application). Switching a rule off or changing its recipient is kept; it is not put back.
An application rule can create a task. On an Application rule, add Create a task to open a task for the applicant, such as Review application. Choose how many days it is due after the event, a priority, and who it goes to: The unit’s property managers (found for each unit when the rule runs, and the organization owner when the application has no unit or the property has no manager), a person, or a team. A general application has no unit, so pick a person or team for it if you do not want the owner. Each application gets one task per rule, even if you complete or delete it, and the task links back to the application.
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.
Every rule says where it came from. The list and the rule editor mark each rule Standard (a rule Return Grid set up for your organization that you have not changed), Customized (a standard rule that your team has edited) or Custom (a rule your team built). Moving a rule, or switching it on or off, does not make it Customized. Changing its name, when it fires, who it tells, its conditions or its actions does. Everyone in your organization sees the same label.
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.
4Team, versus Coordinator
Two independent fields on a request. Confusing them is the second most common mistake, after the order one.
Every request carries two separate fields on its work panel: Team and Coordinator. A request can have neither, either, or both, and one can change independently of the other. Who does each piece of work is a third thing, set per job as Done by.
| Field | What it answers |
|---|---|
| Team | Whose queue the request is in, and who is accountable for it. |
| Coordinator | The one person who owns the request day to day and talks to the tenant. |
Both fields exist so a request can stay with 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. The automatic Coordinator default (whoever first replies or adds a job) only fills an empty field, so it never overrides a rule.
5Reading the rule log
Every rule's decision, kept for 90 days, one row at a time.
From Settings → Workflow Rules, open the History tab (it sits beside Rules and Built-in alerts), 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 or alert, Kind, Triggered by, Outcome, and What it did.
Triggered by names the record the rule or alert was about and links to it, so you can track a notice down. A rent charge or a late fee opens that lease's rent ledger; a ticket, application, task, important date, property, repair item, insurance request or tax form opens its own page; a billing alert opens Usage and Charges. If the record has since been deleted, the row shows its name without a link. The built-in alerts appear here too: Sent, or Not delivered with the reason, for example that nobody was set to receive it. The red number on the Built-in alerts tab counts notices not delivered in the last 30 days, and each alert's row links to them.
Filters across the top: Rule or alert: 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.
6Built-in alerts: who receives them
These messages send on their own. You choose who gets each one.
On the Built-in alerts tab, next to the rule list, the panel lists four alerts that Return Grid sends on its own: Usage charges accruing, Daily allowance used up, Bank feed needs sign-in and Autopay charges failed. Their wording and timing are fixed, so they are not rules. Only the recipients are yours to set. Open the panel with Show.
- Default. Until you change one, the organization owner and all admins receive it.
- Choose recipients. Press Edit on an alert, then tick people, Department groups, or both. Search narrows the list. Each alert is set on its own.
- At least one email address. You cannot save a choice where nobody has an email address. If someone you chose later loses their email or is deactivated and nobody else can receive the alert, the row shows a warning and the alert is held, then sent as soon as someone valid is chosen. It is never sent to Return Grid staff instead.
- Reset. Reset to default puts an alert back to the owner and all admins.
A fifth alert, New lease blocked by an active lease, works a little differently. It is sent when a newly signed lease cannot start because another lease is still active on the unit, and a move-out inspection task is created either way. The unit’s property managers, including everyone in a Department group assigned to the property, always receive the email. In Edit you can add other people or groups on top of them, or untick Send this email to stop the email (the task is still created). The wording is a message template you can edit under Message Templates, and it names the new tenants, the unit and both leases.
The panel also shows when each alert last sent. To share a link that opens it, use ?view=workflow-rules&panel=built-in-alerts.
7What 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.