Auto Attendant and Call Queue Setup — The Complete Guide

Auto attendants and call queues are the two most deployed voice features in Microsoft Teams Phone. They’re also the features most likely to cause confusion during initial setup — not because they’re technically difficult, but because the deployment sequence matters and the Teams Admin Center doesn’t make it obvious.

This guide covers what each feature actually does, the correct setup order, the resource account model that trips most people up, and the PowerShell commands that make repeat deployments faster.

What Auto Attendants and Call Queues Actually Do

These two features solve different problems and are almost always used together.

An Auto Attendant is a call routing and menu system. When a call comes in, the auto attendant answers it, plays a greeting, and routes the caller based on input or schedule. “Press 1 for Sales, press 2 for Support” — that’s an auto attendant. It doesn’t distribute calls to agents. It routes them to the right destination.

A Call Queue distributes calls to a group of agents. Once a call is routed to a queue, it waits in line and rings available agents based on a routing method — attendant, serial, round robin, or longest idle. The queue handles hold music, overflow behavior, timeouts, and agent opt-in settings. It answers calls. The auto attendant sends them there.

In a typical deployment they work in sequence: the auto attendant receives the inbound call, evaluates the menu input or time schedule, and transfers to a call queue. The call queue holds the call and rings the right agents.

The Deployment Order That Actually Matters

Most articles on this topic jump straight to configuration without explaining why the setup breaks when you do it out of order. The reason is resource accounts — and more specifically, license propagation.

The correct deployment sequence is:

Create resource accounts
Assign Teams Phone Resource Account licenses
Wait for license propagation — this is not optional
Create the Auto Attendant
Create the Call Queue
Associate resource accounts to the AA and CQ
Assign phone numbers to resource accounts
Test routing end to end

Steps 1 and 2 have to happen first because auto attendants and call queues can’t be associated to a resource account that hasn’t been licensed. And step 3 — the wait — catches people every time. The license assignment shows as complete in the admin center, but the backend provisioning takes additional time. Try to associate the resource account too early and it either won’t appear in the dropdown or the association will fail silently.

In most tenants, 15–30 minutes is enough. In some environments it takes longer. If a resource account isn’t appearing where it should, license propagation is the first thing to check.

Resource Accounts Explained

Resource accounts are one of the most commonly misunderstood parts of Teams voice configuration, and the confusion is understandable — Microsoft’s documentation doesn’t make the model obvious.

Here’s what you actually need to know:

Resource accounts are not user accounts. They’re service identities — objects in Azure AD that represent a voice feature (an auto attendant or a call queue) rather than a person. They have a UPN, they appear in your tenant’s user list, but they don’t have a mailbox and they can’t sign in.

Every auto attendant and every call queue needs its own resource account. One resource account per feature. You can’t share them.

Resource accounts require a Teams Phone Resource Account license. This was previously called the Virtual User license. It’s free — there’s no additional cost — but it has to be assigned explicitly. An unlicensed resource account cannot be associated with an auto attendant or call queue, and it cannot receive a phone number. For a full breakdown of how resource account licensing fits into the broader Teams licensing stack, see Teams Calling Licensing Templates by Customer Profile.

Phone numbers are assigned to the resource account, not to the feature. When you assign a DID to an auto attendant, you’re actually assigning it to the resource account that’s associated with that auto attendant. This distinction matters when you’re troubleshooting number assignment issues.

Teams Admin Center vs PowerShell

Both work. Which one you use depends on what you’re doing and how often you’re doing it.

The Teams Admin Center is the right tool for visual menu creation, one-off changes, and environments where helpdesk staff need to make adjustments without scripting knowledge. The interface walks you through the configuration in a logical order and makes it easy to see the full call flow at a glance.

The practical limitation is that Teams voice settings are spread across multiple sections of the Admin Center — Voice > Auto Attendants, Voice > Call Queues, Voice > Resource Accounts, and Users — which makes repeat deployments slower than they need to be. One reason many admins move toward PowerShell is simply that the menu-hunting adds up across a multi-site deployment.

PowerShell is faster for bulk changes, more consistent across repeated deployments, and easier to document and hand off. A scripted deployment is also easier to audit — you have a record of exactly what was configured and in what order.

In small environments or single-site deployments, the Teams Admin Center is perfectly reasonable. In larger or frequently changing environments, PowerShell usually becomes the faster operational workflow.

Setting Up a Call Queue

Prerequisites

Before starting, confirm:

MicrosoftTeams PowerShell module installed and connected (Connect-MicrosoftTeams)
Microsoft Graph module installed (recommended for license assignment)
Teams Communications Administrator role or higher
Teams Phone Resource Account license available to assign

Step 1 — Create the Resource Account

New-CsOnlineApplicationInstance `
  -UserPrincipalName "cq-sales@yourdomain.com" `
  -ApplicationId "11cd3e2e-fccb-42ad-ad00-800b93575e19" `
  -DisplayName "Sales Queue"

The Application ID 11cd3e2e-fccb-42ad-ad00-800b93575e19 is the fixed identifier for call queues. Auto attendants use a different ID — covered in the next section.

Step 2 — Assign the License and Wait

Assign the Teams Phone Resource Account license via Microsoft 365 Admin Center or Graph API. Then wait. Do not proceed until the resource account is fully provisioned — 15–30 minutes in most tenants.

Step 3 — Create the Call Queue

New-CsCallQueue `
  -Name "Sales Queue" `
  -RoutingMethod Attendant `
  -DistributionLists @("GroupObjectID")

Routing method options: Attendant (rings all agents simultaneously), Serial (rings in order), RoundRobin, or LongestIdle. Match this to the customer’s call handling expectations before you configure it — changing it after go-live requires a helpdesk ticket or another script run.

Step 4 — Associate the Resource Account

New-CsOnlineApplicationInstanceAssociation `
  -Identities @("ResourceAccountObjectID") `
  -ConfigurationID "CallQueueObjectID" `
  -ConfigurationType CallQueue

Step 5 — Assign the Phone Number

Set-CsPhoneNumberAssignment `
  -Identity "cq-sales@yourdomain.com" `
  -PhoneNumber "+12025551234" `
  -PhoneNumberType CallingPlan

Adjust -PhoneNumberType to DirectRouting or OperatorConnect as appropriate for the deployment.

Setting Up an Auto Attendant

Auto attendants require more setup than call queues because you’re building objects — prompts, menu options, menus, call flows — and assembling them before creating the attendant itself. The pattern makes sense once you see it, but the first time through it feels backwards.

Step 1 — Create the Resource Account

New-CsOnlineApplicationInstance `
  -UserPrincipalName "aa-main@yourdomain.com" `
  -ApplicationId "ce933385-9390-45d1-9512-c8d228074e07" `
  -DisplayName "Main Auto Attendant"

The Application ID ce933385-9390-45d1-9512-c8d228074e07 is the fixed identifier for auto attendants.

Step 2 — Build the Prompt and Menu Options

# Greeting prompt
$greeting = New-CsAutoAttendantPrompt `
  -TextToSpeechPrompt "Thank you for calling. Press 1 for Sales, press 2 for Support."

# Define the call target (a call queue resource account)
$salesTarget = New-CsAutoAttendantCallableEntity `
  -Identity "CallQueueObjectID" -Type ApplicationEndpoint

# Menu option — Tone1 = pressing 1
$salesOption = New-CsAutoAttendantMenuOption `
  -Action TransferCallToTarget `
  -DtmfResponse Tone1 `
  -CallTarget $salesTarget

Step 3 — Create the Menu and Call Flow

$menu = New-CsAutoAttendantMenu `
  -Name "Main Menu" `
  -MenuOptions @($salesOption) `
  -Prompt $greeting

$callFlow = New-CsAutoAttendantCallFlow `
  -Name "Standard Flow" `
  -Menu $menu

Step 4 — Create the Auto Attendant

New-CsAutoAttendant `
  -Name "Main AA" `
  -DefaultCallFlow $callFlow `
  -LanguageId "en-US" `
  -TimeZoneId "Eastern Standard Time"

Step 5 — Associate and Assign

Same pattern as the call queue: associate the resource account to the auto attendant object, then assign the phone number to the resource account.

After-Hours and Holiday Schedules

Most auto attendants need more than a single call flow. A typical production deployment has at minimum:

A business hours flow (the main menu)
An after-hours flow (closed message or voicemail transfer)
A holiday schedule (static dates with their own routing)

Schedules are built with New-CsOnlineSchedule and New-CsOnlineTimeRange, then attached to the auto attendant as additional call flows. The auto attendant evaluates schedules in order — holiday schedule first, then after-hours, then the default flow.

Getting the schedule logic right before go-live prevents the most common AA complaint: “the phone rings through to voicemail on holidays” or “callers hear the main menu at 11pm.”

Full script blocks for schedule configuration are on the PowerShell Reference page.

Common Problems

License propagation delay. Everything looks correctly configured but the resource account won’t associate. This is almost always a propagation timing issue. Wait 15–30 minutes after license assignment and try again before troubleshooting anything else.

Resource account not appearing in the dropdown. Three causes: sync delay (wait it out), license not assigned (check the account in M365 Admin Center), or the object was created with the wrong Application ID (wrong feature type). Verify the Application ID used during New-CsOnlineApplicationInstance.

Call queue agents not receiving calls. The most common causes in order: agent presence is set to Do Not Disturb or Away, the routing method doesn’t match expectations, agents haven’t opted into the queue, enterprise voice isn’t enabled on the agent account, or the Teams client needs a restart. Check presence first — it’s the answer more often than it should be.

Auto attendant not transferring correctly. Usually a misconfigured call target — verify the callable entity Identity matches the actual resource account ObjectID of the destination queue or user. ObjectID mismatches cause silent transfer failures with no error in the Admin Center.

Key Cmdlets Reference

Feature	Primary Cmdlets
Auto Attendant	`New-CsAutoAttendant`, `Set-CsAutoAttendant`
Call Queue	`New-CsCallQueue`, `Set-CsCallQueue`
Schedules	`New-CsOnlineSchedule`, `New-CsOnlineTimeRange`
Resource Accounts	`New-CsOnlineApplicationInstance`, `New-CsOnlineApplicationInstanceAssociation`
Number Assignment	`Set-CsPhoneNumberAssignment`

The Bottom Line

Auto attendants and call queues are not complicated features. The setup becomes complicated when the deployment order is wrong, the resource account model isn’t understood, or license propagation isn’t respected.

Get the sequence right, license the resource accounts before you try to use them, and build your call flows before you build the auto attendant. Everything else is configuration.

For guidance on controlling what users and supervisors can change inside auto attendants and call queues after deployment, see Teams Calling Policies — Calling, Call Park, and Voice Apps Configured Right.