Routing & Automation
Part of Support routing and automation
Routing a ticket by product and issue type
Map product and issue-type combinations to support groups, then handle missing fields, overlapping rules and later corrections.
Route by product and issue type when both fields reliably identify a team that can take the next action. Map the combinations first, then define where a ticket goes if either value is missing, uncertain or corrected later.
Build a destination map
Use a small matrix of supported combinations. For an illustrative service, Product A access questions might go to account support, while Product A fault reports go to technical support. These are example destinations, not product defaults.
| Intake result | Destination to define | Check |
|---|---|---|
| Product and issue type known | Team named for that combination | Can it act on the case? |
| Either field missing | Monitored triage queue | Who obtains the missing information? |
| Fields conflict with the request | Monitored triage queue | Who corrects the classification? |
Assign someone to maintain the map and review misrouted cases. The useful measure is whether the receiving team can advance the request, not whether a rule matched a label.
Check the fields before writing rules
A customer selection, integration value and agent-entered field may have different error patterns. Inspect each intake channel. If a field is absent from an email ticket, a rule that requires it cannot classify that ticket at creation. Treat a keyword in free text as a clue unless the team has an agreed review path.
Zendesk documents custom ticket fields, including fields for product information, and notes they can be used in workflows. Freshdesk documents Type as a default dropdown field that defines the types of issues a user can select, and documents custom ticket fields. None of this establishes that a particular account's form collects the values reliably.
Resolve overlapping rules
Write each route as a complete condition: new ticket, Product A and access issue, then assign the agreed group. Add a default path for tickets outside the map. Check rules that could assign the same ticket to different groups.
Freshdesk creation rules can run the first matching rule or all matching rules. In first-match mode, a broad Product A rule above a specific access rule can prevent the specific rule from running.
In all-match mode, inspect overlapping actions. Zendesk ticket triggers run on creation and updates and perform actions when their conditions are met. The final group depends on the configured rules, not a single matching condition.
Decide what a correction changes
Agree whether changing product or issue type should reroute an unclaimed ticket. If someone already owns the customer reply, a handover may be clearer than an automatic transfer. Record that choice as team policy; it is not a platform default.
Check each important map row with a newly created sample ticket, including missing and conflicting fields. Freshdesk creation rules act on newly created tickets, and its documentation covers testing and troubleshooting those rules. Zendesk ticket events can show field changes and whether a trigger fired. Inspect the resulting group and owner before relying on the map.
