Inbound Email Rules
Inbound rules turn mail from manual triage into a managed process. Instead of reading, sorting, and manually logging every email into CRM, you describe the conditions and actions once, and the portal applies them automatically to each new email.
This is especially valuable for sales and support teams: a request from the website or a client email becomes a CRM request with an owner right away, while routine emails get an auto-reply without waiting for a free manager.
Rules are configured for a connected mailbox in its settings. For how to connect a mailbox, see the Mailbox section.
How a Rule Works
Each rule has two parts:
- Conditions — which emails trigger the rule;
- Actions — what the portal does with a matching email.
When a new email arrives, the portal checks the rules in order and applies the first one that matches. That is why the order of rules matters: keep narrower, higher-priority rules above general ones.
Conditions
Conditions describe which emails fall under the rule. Available conditions:
| Condition | When to use |
|---|---|
| Sender | emails from a specific address — for example, a regular client or partner. |
| Sender domain | all emails from one company (by the part of the address after @). |
| Recipient | emails that arrived at a specific address of a shared mailbox (sales, support, invoices). |
| Subject | emails with a keyword in the subject — "request", "invoice", "complaint". |
| Folder | emails that landed in a specific mailbox folder. |
| Has attachments | emails with files — for example, contracts or documents to review. |
Combine conditions so the rule triggers exactly on the flow you need, not on all mail at once. A condition that is too broad turns automation into a source of errors.
Choose how the editor combines the conditions you add:
- All conditions — the email must satisfy every listed condition;
- Any condition — matching at least one listed condition is enough.
An empty condition list does not narrow the flow, so do not enable such a rule until you test a sample email and confirm that it will not catch all inbound mail.
Actions
Actions describe what happens with a matching email. Available actions:
- Create a CRM request — the email becomes a request the department works with next; its source and content are preserved.
- Assign an owner — the request or thread gets an owner right away instead of waiting for manual distribution.
- Set the thread status — move the correspondence into the needed state (for example, "in progress" or "needs a reply").
- Mark that a reply is required — flag an email that needs an answer, or remove that flag.
- Flag the email — visually highlight important emails.
- Move to a folder — sort emails into folders automatically.
- Send an auto-reply — queue a response from a template (see below).
- Keep the email local — process the email without promoting it to CRM, when no request is needed.
A single rule can perform several actions: for example, create a request, assign an owner, and send an auto-reply to the client.
Auto-reply
An auto-reply queues a prepared response after the email matches the rule; it is sent from this mailbox later, not immediately. If outbound automation is disabled in the mailbox policy, the auto-reply is not sent. Replies to the mailbox itself and messages from no-reply senders are skipped.
When setting up an auto-reply, consider:
- Text or template — exactly what the sender receives. Keep the text short and useful.
- Cool-down period — how long not to send another auto-reply to the same sender, so you do not bury a person under identical emails during a conversation.
- Attempt limit — how many times the auto-reply may go out to one sender at all.
Do not turn the auto-reply into an imitation of a live reply. Its job is to confirm receipt and set expectations on timing, not to replace a manager's work.
After a failure, check the status of the specific queued message or draft and retry only the failed attempt. Retrying the whole operation can create a duplicate.
Rule Priority
The portal applies the first matching rule, so the order decides the outcome:
- keep narrow rules (a specific sender, a specific subject) above broad ones (a whole domain, any emails);
- check that a general rule does not intercept emails that should fall under a specific one;
- disable outdated rules rather than leaving them to affect the flow unnoticed.
Testing on a Sample
Before enabling a rule on the live flow, test it on a sample email. The test shows whether the conditions would trigger and which actions would run — this is how you find conditions that are too broad and rule conflicts before they touch real clients.
Good Practices
- Start with one clear flow: website requests, emails to the support address, invoices from suppliers.
- Make conditions narrow enough that the rule does not capture extra emails.
- Assign an owner in the rule so the request does not sit without one.
- Test a new rule on a sample email before enabling it.
- Use the auto-reply to confirm receipt, not as a substitute for a manager's reply.
- Review rules regularly: disable outdated ones and refine those that trigger incorrectly.
Common Mistakes
- A condition that is too broad — the rule creates requests from all mail, including newsletters and spam.
- No owner in the action — requests pile up without one.
- Several rules conflict — a general rule intercepts emails ahead of a specific one because of the order.
- An auto-reply with no cool-down period — the sender gets identical emails for every message they send.
- A rule enabled without testing on a sample — the errors are only visible on real clients.
Related Sections