Routing & Automation
Part of Support routing and automation
Testing a routing change before all tickets use it
Check a routing rule with expected cases, inspect actual ticket paths and widen the change only after a controlled first release.
Write down the expected ticket destinations, check them with safe sample cases, then expose only a segment the configured system can reliably identify. Inspect the final group, owner and outgoing messages before expanding the rule. A rule preview alone does not show the complete ticket path.
Define the change and expected results
Record the existing route, proposed condition, affected channels, receiving group, fallback and person responsible for the change. List other rules that might assign the same ticket or send a message when it is created.
| Case | Expected result to record before the check |
|---|---|
| Intended match | New group receives the ticket and its next owner is visible |
| Similar excluded issue | Existing route remains in place |
| Missing field | Monitored triage receives the ticket |
| Field corrected later | Agreed correction or handover policy applies |
| Overlapping rule | Final group and message set match the intended result |
Use invented or de-identified details. Record the expected result before creating a sample ticket.
Check the available environment
A separate environment helps only if it contains the relevant fields, groups, rules and notifications. Zendesk sandboxes are included with specified Enterprise plans and available as an add-on from other eligible plans.
Replication has limits: for example, copied webhooks are inactive by default and external support addresses change in the sandbox. Inspect what was copied before relying on a result.
Freshdesk's documentation covers testing and troubleshooting ticket creation rules, and notes that these rules act on newly created tickets.
Zendesk ticket Events can show field changes, trigger actions and notifications. In either product, inspect the final ticket as well as the rule log, because another rule may change the result.
If no suitable separate environment is available, plan a supervised check using safe ticket details, a test recipient and an agreed way to stop the change. Any live exposure must be small enough for the team to inspect and correct promptly.
Sandbox Environment Capabilities: Zendesk vs Freshdesk
- Zendesk Sandbox Availability
- Included with Enterprise plans; add-on for other eligible plans
- Freshdesk Testing Support
- Covers testing and troubleshooting automation rules on ticket creation
- Replication Limitations
- Copied webhooks inactive by default; external addresses change in sandbox
- Event Tracking Capability
- Zendesk Events show field changes, triggers, and notifications
Limit exposure and decide when to widen
Use a condition the actual account can identify, such as a dedicated support address or a defined product value. Confirm that nearby excluded tickets remain outside it.
If no reliable segment exists, keep the rule out of general intake while the team resolves that limit. Do not describe a segment as a percentage rollout unless the configured system provides one.
During the initial exposure, inspect each matching ticket and nearby excluded cases for destination, assignee, transfers and outgoing messages. Ask the receiving team whether it can act on the work.
Record each exception with its ticket ID, expected route, actual route and correction owner, without copying unnecessary customer details.
Set the release decision in advance: intended tickets reach a staffed destination, excluded cases retain their route, missing-field cases remain visible and no extra customer message is sent.
If an exception appears, pause expansion and check tickets already moved. Restoring the old rule does not necessarily reverse earlier ticket changes.
Key Metrics for Safe Routing Rule Testing
- Rule Log Review Completed
- Yes – verified before expanding
- Final Ticket Inspection Done
- Yes – including owner, group, and outgoing message
