Incident Routing Based on Service Offering with Mixed Support Needs

[Hugo van QW]

Background:

• We’re releasing a new tool that will be available to approximately 150,000 users.

• Incoming incidents are submitted via record producers on the portal.

• Incidents are routed to a support team based on the Service Offering (SO).

The Problem:

• The current SO-based routing sends all incidents to the developer team, which is not equipped to handle end-user support at this scale.

• Some issues (e.g., login problems) should go to the Service Desk, while other issues (e.g., bugs, technical faults) should go directly to the developer team without passing through the Service Desk.

• We’ve looked into:

  • Assignment Rules: Unfortunately, SO-based routing overrules them.

  • Smart Flow: The challenge here is that it re-triggers on every reassignment, which risks locking the ticket into a single group unintentionally.

What We’re Looking For:
We need a way to:

1. Route incidents intelligently based on issue type, not just the Service Offering.

2. Ensure that some tickets can bypass the Service Desk, while others must go through it.

3. Retain the flexibility to reassign tickets manually when needed.

Question:
Has anyone faced a similar situation? How did you handle complex routing where Service Offering isn’t enough to determine the correct assignment group? Any ideas on combining SO with other conditions (like category, subcategory, or custom fields) without causing assignment conflicts?

[Chai Maddula]

Hi @Hugo van QW 

Have you tried Dynamic Routing table option?

Try Creating a routing configuration table with columns like:

• Service Offering
• Category
• Subcategory
• Issue Type
• Assignment Group

Then use a lookup script in your business rule to check this table and assign intelligently

If my response solves your query, please marked helpful by selecting Accept as Solution and Helpful

[Hugo van QW]

Thanks for the suggestion. This sounds like a smart, very flexible and scalable suggestion. It does require a custom table, I think, but definitely an option I can discuss with my team.

[surajit3]

Another option i can think of is a data lookup table 

[Hugo van QW]

Thanks, that could help. Our aim is to stay OOB where possible without any scripting, and this suits that approach (except for a possible custom field). I'll discuss this option with our team.