Routing Rules
One shared mailbox, several projects. A routing rule says "mail like this belongs to that project" — so acme@support.you.com can feed Acme's project while everything from contoso.com goes to Contoso's, all through a single support@ address.
Rules are scoped to an inbox, not to the tenant: two mailboxes in one tenant may legitimately route the same domain to different projects.
Match types and precedence
A rule matches on one of two things, and the type itself is the precedence order:
| Order | Match type | Matches against | Example pattern |
|---|---|---|---|
| 1 | Recipient address | Each address in the To header, lowercased | acme@support.you.com |
| 2 | Sender domain | The part after @ in the From address | acme.com |
| 3 | (fallback) | — | The inbox's default project |
Recipient wins because it's the stronger signal — the address the sender deliberately wrote to. Sender domain is a guess about who someone is, and it fails exactly when customers mail in from gmail.com.
Recipient matching reads the To header only. A CC'd support address is a bystander on someone else's conversation, not a request addressed to that queue.
:::tip Aliases and plus-addressing
Recipient rules match mailbox aliases and plus-addressing, which is how one mailbox segregates customers who all send from different domains. Give each customer their own alias — acme@, contoso@ — and route on that.
:::
Adding rules is safe
Routing is additive by construction. Mail matching no rule still lands in the inbox's default project, so adding a rule never silently redirects traffic that was already flowing somewhere else.
Rules can be disabled rather than deleted, which lets you park one without losing it — the alternative is deleting and retyping it, which is how routing gets retyped wrong.
Only one destination is allowed per pattern per match type per inbox, so "which rule wins" is never ambiguous.
Pattern format
Ticku validates the pattern against the match type and rejects a mismatch, because a domain typed into an address rule silently never fires:
- Sender domain — a bare domain:
acme.com. No@, no scheme, no path. - Recipient address — a full address:
acme@support.you.com.
Patterns are stored lowercased.
Per-rule overrides
Beyond the destination, a rule can override the inbox's defaults. Every override is optional — leaving one unset means inherit from the inbox, so an inbox-level change still propagates to every rule that hasn't deliberately opted out.
| Override | Effect |
|---|---|
| Priority | Priority for tickets this rule creates |
| Send acknowledgement | Whether to acknowledge the requester |
| Notify on comment | Whether comments are mailed out |
| Notify on status change | Whether transitions are mailed out |
| Subject | Files tickets under a Subject folder in the destination project. Must belong to that project |
| Assignee | Auto-assigned on top of the CC and @mention assignees ingestion already adds |
If the overridden Subject is deleted or the assignee is deactivated, the rule reverts to inheriting from the inbox. Mail keeps flowing to the right project and only the embellishment is lost — which beats the rule being deleted and that customer's mail quietly falling back to the default project.
Testing a rule
Simulate takes a sender address and a recipient address and reports which rule would win and where the ticket would land — without ingesting anything. Use it after adding a rule, and especially when several could plausibly match.
What routing does not do
- Replies never re-route. A reply threads onto its existing ticket and stays in that ticket's project, whatever the rules now say.
- Routing doesn't filter. Whether a message is accepted at all (no-reply and bounce handling) is decided at the inbox level, upstream of deciding where it goes.
- Destinations must be Support projects, the same rule that applies to an inbox's default.
Deleting a rule
Rules are hard-deleted. Tickets the rule routed are left intact and simply fall back to the inbox's settings.