"Calling policies and dial plans" is one of the most-searched Teams Phone topics — and one of the most confused, because Teams has three different objects that all sound like "policy" and all affect calling. Getting them straight is the difference between a clean Direct Routing deployment and six months of "why can't the 4th floor dial out?"
This guide covers all three — dial plans, voice routing policies, and calling policies — with the enterprise patterns and failure modes we see in practice.
Object 1: The Dial Plan (Normalization)
A dial plan is a set of normalization rules that rewrite what users dial into E.164 (+ country code, number) before the call is routed. Users dial what they're used to — 4-digit extensions, 7-digit local numbers, 9 for an outside line — and the dial plan translates it into the single canonical format Teams and your SBC expect.
Each rule is a name, a regular expression pattern to match, and a translation to apply. A classic migration rule:
- Name: 4-digit extension to E.164
- Pattern: ^(\d{4})$
- Translation: +1555123$1 (where 555123 is your DN range block)
Teams dial plans come in four scopes. From lowest to highest precedence:
- Service dial plans — built in, per country/region; you can't change them
- Tenant-global dial plan — your baseline normalization rules for all users
- Site-scoped dial plans — per network site, useful for multi-site E911
- Group-assigned dial plans — assigned to groups, highest precedence; ideal for acquired companies or a legacy extension range that only one division still uses
A user's effective dial plan is the service plan plus the most specific tenant rules that apply. This layering is intentional and powerful — and it's also where stale per-user assignments from a pilot group quietly corrupt dialing for years.
Object 2: The Voice Routing Policy (Getting to the SBC)
Normalization decides what the number is; the voice routing policy decides how the call leaves. With Direct Routing, the chain is:
- PSTN usage — a named container (e.g., "US-and-International")
- Voice route — a number-pattern regex mapped to your SBC's FQDN, with a priority order
- Voice routing policy — a set of usages, assigned to users
The pattern every enterprise should start with: one route matching ^\+1(\d{10})$ to your primary SBC, and a catch-all route matching ^\+\d+$ to the same or paired SBC at a lower priority. Assign the policy broadly. Then split by site or country only when you have a reason — least-cost routing, local breakouts, regulatory routing.
Object 3: The Calling Policy (User Features)
The calling policy governs user-level calling behavior: whether users can change call-forwarding settings, whether delegation and simultaneous ringing are allowed, whether voicemail is enabled, whether private calling is blocked, and busy-on-busy behavior. Crucially, several settings are admin-enforced — "on but user can't change," or "off" — which is what makes this a governance tool, not a preference list.
Two enterprise patterns worth adopting:
- Call-forwarding control — forwarding to arbitrary external numbers is the classic toll-fraud laundering path. Admin-enforce forwarding to internal numbers only, or require approval workflows.
- Delegation — executive assistants and help desks live on delegation; enabling it deliberately (and documenting which groups get it) prevents a hundred individual support requests later.
The Mistakes That Break Enterprise Dialing
- Regex errors — an unescaped digit class or missing anchor matches too much or nothing; patterns must be anchored (^...$) to avoid surprises
- Dial plan without a voice route — the number normalizes perfectly and then the call fails, because no route matches the translated E.164 string
- Legacy habits forgotten — users who dialed 9-first on the old PBX will keep trying; add a translation rule during migration, and retire it deliberately
- Stale per-user/group assignments — pilot dial plans left on migrated users cause site-to-site inconsistencies that are miserable to diagnose
- Testing in production — every rule should be tested with the translation tools before assignment, not by asking a user to "try dialing now"
Testing Correctly
Test normalization with the dial plan translation tool in the Teams admin center or PowerShell (the effective-dial-plan cmdlets) before you assign anything to a real user. Verify a handful of representative inputs for every population: 4-digit extension, 10-digit local, +E.164 international, 911 and the emergency pattern your jurisdiction requires. Then test end-to-end through the SBC.
Migrating a PBX with years of dialing habits? That translation layer — old habits to a clean E.164 model — is exactly the work we do. Talk to us about your migration, or read the SBC setup guide for the infrastructure side.