Auto-Routing in Console

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.

[H2] 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.