Key Takeaways

• Console routes every request to the right person or team without asking the employee to pick a queue, working in two stages: first to the correct workspace such as IT, HR, or RevOps, then to an individual, group, or on-call rotation inside it.

• Those routing rules are written in plain natural language rather than decision trees or code, and they support round-robin, time-based, and department-based assignment, with several signals combinable in a single rule.

• The rules draw on a context graph built from connected systems such as Okta, Google Workspace, Slack, Jira, Jamf, and Workday, so routing can factor in a requester's department, location, manager, and seniority.

• Workspaces stay isolated by default, so HR cannot see IT tickets and vice versa, though cross-workspace handoffs can be configured when one team needs to pass work to another.

• Assignment lands in the Inbox within seconds of ticket creation with category and fields set automatically, admins can test routing in simulation mode before it goes live, and email-to-case requests run through the same pipeline as Slack.

How auto-routing works in Console

Console automatically determines where every request should go without requiring end users to select the correct team. Routing happens in two stages: first at the workspace level, then within the workspace to the appropriate individual, group, or rotation.

All routing logic is written in plain natural language. There are no decision trees, no conditional builders, and no code.

Natural language routing rules

Admins write routing instructions in plain English. For example: for security issues, assign to Marcus; for laptop issues, assign to the on-call rotation; otherwise route to Tim.

Rules can reference:

• Individual users

• Groups

• Departments

• Rotation schedules

Routing supports round-robin assignment across a group of agents. Round-robin logic tracks ticket load per agent and who received the last ticket to maintain fairness.

Time-based routing is supported. For example, if a request comes in during PST hours, route to one person; otherwise route to on-call.

Department-based routing is also supported. For example, route Salesforce issues between two agents, syncing issues to a specific person, otherwise round robin.

Routing rules can reference any data available in the context graph, including department, title, location, manager, and app access. Multiple signals can combine in a single rule, such as routing to a specific person if the requester is a VP and the issue is security-related.

Routing rules are configured independently per workspace. IT, HR, and RevOps each maintain their own routing logic.

Workspace-level routing (macro routing)

Before intra-workspace routing occurs, Console determines which workspace a request belongs to. This macro-level routing is deterministic. Once a workspace is identified, the request is locked to that workspace.

Workspace determination is based on message content and the policies and workflows configured across workspaces. End users do not need to know which team to contact.

For example:

• A Salesforce request routes to RevOps

• A PTO request routes to People Ops

• A laptop issue routes to IT

Each workspace is fully independent in terms of routing rules, playbooks, articles, and integrations. Once inside a workspace, the AI cannot access other workspaces unless explicitly configured on the backend.

Workspace-level isolation ensures HR cannot see IT tickets and vice versa. Cross-workspace routing can be configured if one team needs to hand off work to another.

Context graph as routing intelligence

Console ingests data from connected systems such as Okta, Google Workspace, Slack, Jira, Jamf, and Workday to build a context graph. This graph provides structured knowledge about every user, including department, title, manager, location, laptop, and app access.

Routing decisions leverage this context. For example:

• A U.S.-based user can be routed to a U.S. team

• A Brazil-based user can be routed to a Brazil team

• The agent on call in the requester’s timezone can receive the ticket

Requester seniority can influence routing and priority simultaneously. Console also knows who a user’s manager is, enabling manager-based routing logic inside playbooks.

AI-powered assignment in Inbox

As tickets land in Inbox, the AI reviews each one and applies the configured routing rules automatically. Assignment happens in near real time, often within seconds of ticket creation.

At the same time, the AI sets the category and relevant custom fields so the receiving agent has full context immediately.

If an agent replies to a ticket, Console can auto-assign that ticket to the replying agent to maintain clear ownership.

Assignment logic can be tested in simulation mode. Admins can input a test message or replay an existing request to see exactly which agent would receive it before going live.

Routing rules depend on workspace membership. If a target user is not added to the workspace, routing cannot assign to them. The fix is simply adding the user to the workspace.

Email-to-case routing

Console supports email-to-case. Emails sent to a configured address create tickets and enter the same routing pipeline as Slack-sourced requests.

Email-sourced tickets go through the same:

• Routing logic

• Categorization rules

• SLA policies

Emails from external parties such as former employees or third parties can be routed automatically to the appropriate team. If an email comes from an unrecognized domain, routing rules can auto-assign it to a specific team member or group.

Bi-directional sync is maintained for email tickets so replies from agents in your ticketing system of choiceare sent back to the original sender.

FAQs

What routing methods does Console support?

Routing rules are written in plain language and support round-robin across a group of agents, time-based routing by hours or timezone, and department-based routing. Several signals can combine in one rule, such as sending a VP's security issue to a specific person.

Can routing use identity and HR data like department, location, or seniority?

Yes. Console builds a context graph from connected systems like Okta, Google Workspace, Jamf, and Workday, so a rule can route by a requester's department, location, manager, or seniority without anyone tagging the ticket by hand.

Does auto-routing work for email tickets, not just Slack?

Yes. Console supports email-to-case: emails sent to a configured address become tickets and run through the same routing, categorization, and service-level-agreement (SLA) rules as Slack requests, with two-way sync so agent replies reach the original sender.

Can you test routing rules before turning them on?

Yes. Console includes a simulation mode where an admin enters a test message or replays a past request to see exactly which agent it would route to, so rules are validated before they affect live tickets.

What is the difference between ticket routing and ticket deflection?

Routing and deflection solve different parts of the same problem. Deflection resolves a request before it ever becomes an agent ticket, usually through self-service answers or automation, so the volume reaching your team drops. Routing takes the tickets that do come in and sends each one to the right person or team. Console's auto-routing handles the second job: every request still reaches an owner, just without the employee having to pick a queue.