Email Rules¶
Email rules control how incoming emails are processed by the platform. They determine which ticket type is created, how fields are populated, and how emails from specific sources are routed, all based on configurable conditions.
Navigation
Configuration > Email > Email Rules on the GRC-ITSM website navigation.
How Email Rules Work¶
When an email arrives in a configured mailbox, the platform evaluates it against the email rules in order. If a rule's conditions match the incoming email, the rule's actions are applied. If no rule matches, the email is processed using the mailbox's default settings.
Rules are processed sequentially from first to last. More specific rules should be placed above more general ones to ensure emails are matched by the most appropriate rule first.
Rule Types¶
| Type | Purpose |
|---|---|
| Help Request Rules | The primary rule type. Maps information from incoming emails to ticket fields and controls which ticket type is created |
| Integration Email Rules | Designed for emails from monitoring tools and integrations (e.g., SCOM, security scanners). Maps integration-specific content to ticket fields |
Conditions¶
Rules match incoming emails based on properties of the message:
| Condition | What It Matches |
|---|---|
| From Address | The sender's email address or domain |
| Subject Line | Text patterns in the email subject |
| Customer/User | Whether the sender matches an existing user in the platform |
Actions¶
When a rule matches, it can perform the following actions:
| Action | Purpose |
|---|---|
| Set Ticket Type | Create a specific ticket type instead of the mailbox default |
| Map Fields | Populate ticket fields from email content |
| Link to Asset | Automatically link the ticket to an asset based on content in the email (e.g., device names from monitoring alerts) |
| Set Priority | Override the default priority based on the email source or content |
Common Rule Patterns¶
Routing Monitoring Alerts¶
Emails from security monitoring tools (Huntress, Defender, SentinelOne) can be routed to the correct ticket type and team:
| Condition | Action |
|---|---|
| From address contains huntress.io | Create an Alert ticket, assign to the Continuous Monitoring team |
| From address contains microsoft.com AND subject contains Defender | Create an Alert ticket, set priority based on severity keywords |
Routing FedRAMP Communications¶
For organizations with a FedRAMP Security Inbox:
| Condition | Action |
|---|---|
| From address domain is fedramp.gov or gsa.gov | Create a high-priority Incident ticket, assign to senior security personnel |
Separating Internal vs External Requests¶
| Condition | Action |
|---|---|
| From address matches the organization's domain | Create a Service Request |
| From address does not match any known user | Create a general ticket with lower priority for triage |
Relationship to Ticket Rules¶
Email rules and ticket rules serve different purposes:
- Email rules fire during email processing, before a ticket is created. They determine which ticket type is created and how fields are initially populated
- Ticket rules fire after a ticket is created or updated. They handle further routing, assignment, notifications, and field updates
For complex routing, the two can work together: an email rule creates the right ticket type with the right category, and a ticket rule then assigns it to the correct team and sends notifications.