Skip to main content

​
Overview

When a customer calls one of your project’s numbers, Uservox needs to decide which process — and which flow within that process — should handle the call. Incoming call routing controls that decision, from a single project-wide default down to per-number, time-windowed overrides. This builds on the number-based routing described in Setting Up and Monitoring Incoming Calls — this page covers the Conditional Flow routing added under Default Incoming by Phone Number.

​
Where to Configure It

  1. Open Account Settings → Project Settings.
  2. Find Default Incoming Routing and Default Incoming by Phone Number.
Advanced Settings card showing Default Incoming Routing and a Conditional Flow ID time-window rule

​
Default Incoming Routing

At the top of the card, Default Process and Default Call Flow set the fallback: any incoming call that doesn’t match a more specific rule below is routed here. If you pick a Default Process that has an associated flow, Uservox shows a Use Suggestion prompt to fill in the matching Default Call Flow automatically.

​
How the Flow Is Actually Chosen

Default Call Flow above (and its per-number equivalent) is the last fallback, not the primary source of truth. For every incoming call, Uservox decides the flow in this order:
  1. Returning lead — if the caller is already partway through a process, it uses that lead’s current state’s own Make Call settings.
  2. New lead / no active history — otherwise, it uses the process’s own first Make Call node’s Flow ID — not the Default Call Flow field.
  3. Only if the process has no Make Call action at all — it falls back to Default Call Flow (or the per-number Flow) configured above.
In practice, tier 3 is rarely reached — almost every process has at least one Make Call node, so that node’s own Flow ID is what actually answers the call. This is also why the Use Suggestion prompt exists: Uservox computes tier 2’s value and offers to fill Default Call Flow to match it, so the field at least documents reality — but it isn’t what’s read at call time unless the process truly has no call action. To change which agent answers incoming calls, edit the process’s Make Call node directly (see Process Configuration Guide) — changing Default Call Flow alone won’t do it if the process already has a Make Call node with its own Flow ID.

​
Per-Number Routing with Time-Window Conditions

Under Default Incoming by Phone Number, click + Add Number to override routing for a specific inbound number. Each number row has:
  • Phone Number, Process, and Flow — the base override for that number.
  • Overrides — opens a Conditional Flow ID editor, letting you route the same number to different flows depending on when the call comes in.
Inside a conditional, set:
  • Start / End — the time window the rule applies in.
  • Days — which days of the week the rule is active (leave empty to apply every day).
  • Then use this Flow ID — the agent/flow to use for calls matching this window, selected directly or via a dynamic parameter.
Add multiple conditionals to cover different windows (e.g. business hours vs. after-hours) on the same number; calls outside every conditional window fall back to that number’s base Process/Flow.
A conditional isn’t active until a Flow ID is set — the editor flags this with “Flow ID is required for an conditional to take effect.”

​
Frequently Asked Questions

The call falls back to that phone number’s base Process and Flow. If the number itself has no override configured, it falls back further to the project’s Default Process. Which agent actually answers within that process still follows the tiered order above — the process’s own Make Call node wins over Default Call Flow unless the process has no call action at all.
Yes — add separate conditionals with different Days selections, each pointing at its own Flow ID.