Ticket Rules¶
Ticket rules allow administrators to define conditional actions that execute automatically when tickets meet specific criteria. Rules evaluate ticket properties at creation or update and perform actions like assigning the ticket to a team, setting a priority, notifying specific people, or updating fields - all without manual intervention.
Navigation
Configuration > Tickets > Rules on the GRC-ITSM website navigation.
How Rules Work¶
Each rule follows an if-then pattern:
- Criteria (IF) - define the conditions that must be met for the rule to fire. Conditions can be based on any combination of ticket properties: who submitted it, which category it falls under, what ticket type it is, which keywords appear in the summary, and more
- Actions (THEN) - define what happens when the criteria are met. Actions can assign the ticket, set field values, send notifications, apply SLAs, or trigger other automated behaviors
Rules are evaluated when tickets are created or updated. Multiple rules can apply to the same ticket, and rules are processed in the order they are configured.
Criteria¶
Criteria define the conditions under which a rule fires. Conditions can be combined to create precise matching logic.
Common Criteria¶
| Criteria | Example |
|---|---|
| Ticket type | Rule only applies to change requests, or only to incidents |
| Category | Rule fires when the ticket is categorized as Flaw Remediation |
| Submitter | Rule fires when the ticket is created by a specific user or email address |
| Source | Rule fires based on how the ticket was created (email, portal, API, automation) |
| Priority | Rule fires for tickets at a specific priority level |
| Team / Agent | Rule fires based on current assignment |
| Keywords | Rule fires when the summary or description contains specific terms |
| Custom fields | Rule fires based on custom field values on the ticket (some field types may require a lookup field) |
Combining Criteria¶
All criteria on a single rule are combined with AND logic - every condition must be met for the rule to fire. For example:
- Ticket type is Incident AND priority is Critical - route to the on-call team
- Source is Email AND submitter email contains @vendor.com - assign to the vendor management team
- Category is Flaw Remediation AND ticket type is Change Request - assign to the engineering team and notify the ConMon lead
To achieve OR behavior, create separate rules for each alternative condition set. For example, to route tickets from two different sources to the same team, create one rule per source rather than a single rule with an OR condition.
Actions¶
Actions define what the rule does when its criteria are met.
Assignment Actions¶
| Action | Purpose |
|---|---|
| Assign to agent | Route the ticket to a specific agent |
| Assign to team | Route the ticket to a team queue for pickup |
| Set agent based on round-robin | Distribute tickets evenly across a team |
Field Update Actions¶
| Action | Purpose |
|---|---|
| Set priority | Override or set the ticket priority |
| Set category | Assign or change the ticket category |
| Set status | Move the ticket to a specific status |
| Set SLA | Apply a specific SLA policy to the ticket |
| Set custom field values | Populate any custom field on the ticket |
Notification Actions¶
| Action | Purpose |
|---|---|
| Send email notification | Notify specific people or distribution lists when the rule fires |
| Send agent notification | Send an in-platform notification to specific agents |
For more advanced actions like automatically adding notes to tickets, use ticket rules in combination with webhooks and n8n workflows.
Common Rule Patterns¶
Auto-Assignment by Category¶
Route tickets to the right team based on the work category, so agents don't need to manually triage and reassign incoming work.
| Criteria | Action |
|---|---|
| Category is Flaw Remediation | Assign to the Engineering team |
| Category is Configuration | Assign to the Engineering team |
| Category is Maintenance | Assign to the Infrastructure team |
Priority-Based Escalation¶
Ensure high-priority tickets get immediate attention by notifying the right people automatically.
| Criteria | Action |
|---|---|
| Priority is Critical AND ticket type is Incident | Assign to the on-call agent, send email notification to the security lead |
| Priority is High AND category is Security | Assign to the security operations team and notify the team lead |
SLA-Based Escalation
Escalation based on SLA time remaining (e.g., notify when an SLA is about to breach) is handled through the dedicated SLA Escalation Rules under Service Level Agreements, not through ticket rules. Use ticket rules for criteria based on ticket properties, and SLA escalation rules for criteria based on SLA timers.
Source-Based Routing¶
Route tickets differently depending on how they arrived in the platform.
| Criteria | Action |
|---|---|
| Source is Email AND submitter is from a specific domain | Assign to the appropriate team and set the category |
| Source is API AND ticket type is Alert | Assign to the security operations team |
Automated Notifications¶
Keep stakeholders informed without agents needing to manually send updates.
| Criteria | Action |
|---|---|
| Ticket type is Change Request AND status changes to Approved | Notify the implementation team |
| Ticket type is User Access Request AND status changes to Completed | Notify the submitter that their access has been provisioned |
Rule Ordering¶
Rules are evaluated in the order they appear in the configuration. When multiple rules match the same ticket, all matching rules execute in sequence. If two rules set the same field to different values, the last rule to execute wins.
Order Matters
Place more specific rules above more general ones. A rule that matches "Critical Incidents from the security scanner" should come before a general "all Incidents" rule, otherwise the general rule may set values that the specific rule then has to override.
Best Practices¶
Start simple. Begin with a few high-value rules (auto-assignment by category, critical incident escalation) and expand as you identify more patterns. Overly complex rule sets are difficult to troubleshoot when something routes unexpectedly.
Document your rules. Use clear, descriptive names for each rule so other administrators can understand what it does without reading through all the criteria and actions. A rule named "Route flaw remediation CRs to engineering" is immediately understandable.
Test before deploying. Create a test ticket that matches your rule criteria and verify it behaves as expected. Check that the assignment, notifications, and field updates all fire correctly.
Avoid conflicting rules. If two rules can match the same ticket and set the same field to different values, the result depends on rule ordering. Review your rules periodically for conflicts, especially as the rule set grows.
Use rules alongside webhooks. For more complex automation logic that goes beyond what ticket rules can handle natively, use rules to set a field or status that triggers a webhook, which then fires an n8n workflow for advanced processing.