Inbox Rules
Rules decide what happens to an incoming message, by matching on part of it.
Where to find it
Architect Panel → Integration & Connections:
- E-mail Accounts — the accounts mail is sent and received through
- E-mail Inboxes — monitored mailboxes and their rules
Architect Panel → Data:
- Data Extraction — a common action for structured mail
How a rule works
Each rule names a component of the message — the sender, the subject, the body — a comparison, and a value to compare against. Where it matches, the rule's action runs.
Match on the most stable thing available
Senders are more durable than subjects. A subject line containing a reference is reliable while the sending system keeps that format and breaks silently when it changes — and it will change without telling you.
Where you can key on the sending address or a stable identifier, do.
Order matters
Specific rules before general ones. A rule catching everything from one domain will swallow the message from that domain that needed different handling, and it will do so silently.
Review the order whenever you add a rule, not only when something goes wrong.
The fallback is the important part
What happens to a message matching nothing is more consequential than any individual rule, because it is where the surprises land — a new sender, a changed format, somebody replying to the wrong address, an out-of-office.
Route unmatched mail somewhere a person looks. An inbox that silently discards what it does not recognise loses enquiries, and nobody finds out because there is nothing to find.
Watch what falls through
The unmatched pile is your best source of new rules. If the same kind of message arrives repeatedly and matches nothing, that is a rule waiting to be written — and until it is, somebody is handling it by hand.
Automatic replies and loops
Out-of-office replies, delivery failures and automated acknowledgements all arrive in the inbox. If your rules generate a reply, be careful not to reply to a machine that will reply to you — mail loops are easy to create and generate a great deal of traffic before anybody notices.
Exclude automated senders explicitly rather than assuming they will not match.
Test with real messages
Forward genuine examples rather than composing test messages. Real mail carries the formatting, quoting, signatures and encoding that break rules; a clean test message proves very little.
Structured mail suits extraction
Where a sender transmits structured data — a CSV, a form submission, an XML payload — handing the attachment to data extraction is usually better than parsing it in a rule. The mapping lives somewhere visible and every run is logged.
Worked example
A referrals inbox keys on the partner's sending domain rather than the subject line, which had been changing. Unmatched mail routes to a queue a coordinator checks each morning; two recurring patterns found there in the first month became rules three and four.
Recommendations
- Match on the sender where you can.
- Specific rules first, and re-check the order on every addition.
- Route unmatched mail to a person, never to nothing.
- Test with real forwarded messages.