When a call arrives on one of your organization's numbers, something has to decide who it rings. In xMatix that decision is an inbound route: a per-number rule, authored by your administrators, that sends the number's calls to one of three kinds of target. This page explains the model — the screens that author it are covered in Telephony configuration, and it applies where your organization has telephony configured.
Numbers and routes
Your organization's phone numbers are provisioned by xMatix; administrators label them and control which are active, but do not create them. Each active number can carry one active route — the called number is the whole routing key, which is why teams usually want one number per purpose (support line, sales line) rather than one number for everything.
Before any routing happens, the caller is matched to a contact and account from your records, so whoever the call eventually rings sees a name, not just a number.
Authoring a route
Routes live under Setup → Telephony → Routing. The list shows each route's Name, Number, Target, Status (the sync status explained below) and Updated, with Edit, Resync and Delete per row; New Route opens the dialog.
- 1
Name is for administrators — call it after the line's purpose, one number per purpose.
- 2
Number lists the organization's provisioned inbound lines; each active number carries one active route.
- 3
Route to picks the target type: Queue (offered to the queue's available members), AI agent, or Human agent (rings one person).
- 4
The selector below changes with the target type — here a Queue; for the other types a named AI agent or a user.
- 5
Active decides whether the route takes part; an inactive or missing route falls back to the organization-wide ring.
A route has five controls: Name; Number (one of the organization's provisioned lines); Route to — Queue, AI agent or Human agent; the matching selector (a queue, a registered AI-agent identity, or a user); and Active. Creating or editing a route saves the row and immediately tries to push the matching dispatch rule to the telephony infrastructure. Before saving, confirm the target is active and able to take work — an inactive human-agent binding or an empty queue does not break the number, it sends its calls to the organization-wide ring described below.
The three target types
| Target | What happens to the call |
|---|---|
| Queue | The call becomes a work item in an omni-channel queue and is offered to one available member of the queue's agent pool, per the queue's routing model — direct, round robin, load balance, or skill-based. That agent's softphone rings, carrying the queue context. |
| Human agent | The call rings exactly one named person's softphone — a private line or a named-account arrangement expressed as routing. |
| AI-agent identity | The call is dispatched to a named AI-agent identity registered by your administrators, and no human is rung for it. The identity and its activation are yours to manage; retiring one that a route still targets is blocked until the route is retargeted. |
Queues are the same queue machinery used across channels — a queue declares which channels it serves, and its membership is a resource group whose active members are the routing candidates. See Telephony configuration for the queue fields.
Fallback: the organization-wide ring
Routing is deliberately fail-open. If a number has no active route, if a route's target can't take the call (an inactive agent, a queue with nobody available), or if route handling fails outright, the call falls back to ringing every signed-in agent on your organization. A misconfigured route therefore makes calls noisier, not lost — the failure mode is everyone's phone ringing, which has the useful property of being impossible to miss.
Keeping routes in sync
A route is not just a database row — it must also exist as dispatch configuration in the telephony infrastructure that actually answers the number. xMatix reconciles the two automatically on every route change, and each route displays a Status of Pending, Synced or Error (with the error text when a push fails). A failed or pending route can be re-synced explicitly with Resync, and simply opening the routing screen re-drives anything left pending. Deleting a route removes its dispatch rule in the same reconcile. Until a new route syncs, calls on that number keep flowing via the previous behavior or the organization-wide fallback rather than dropping.
Common questions
What happens when nobody in the queue is available?
The call falls back to the organization-wide ring — every signed-in agent is offered it, not just the queue's members. There is no built-in hold-music waiting room in this model: a call that can't be placed with its intended pool escalates to everyone rather than parking. Staff the pool (or widen the resource group) to keep calls where you intended them.
Can one number ring a queue during the day and an AI agent after hours?
Not with routes alone — a route has no schedule; it is one number, one target. Time-of-day behavior needs either separate numbers or changing the route's target (routes can be edited and re-sync automatically). If schedule-driven routing matters to you, raise it with your account team so it's on the record as demand.
Do declined and unanswered calls disappear?
No — every inbound call is a record in the call register from the moment it rings, whatever happens next. Unanswered calls end as Missed, keep their caller match and timings, and are the natural start of a call-back list.