Polices are used throughout Teams for assigning settings to users, and in some special cases, to Network Topology sites. There are a few methods to apply user based policies, each with their own benefits and drawbacks.

With Teams policies, only one policy is applied, and the entire policy is applied. This is different than other methods like Group Policy or NTFS permissions.

If you have not created any new policies, then only the default policy, called the Global policy, applies. This is the lowest precedence policy, Global settings are applied only if no other policy has already been applied.

The other policy is a user-assigned policy. It is applied as the name applies, directly to a user. If a user has a user-assigned policy, its settings will have precedence over a Global policy.

In certain cases, policies can also be assigned to Network Topology sites. There are three such policies:

These are the Network Roaming Policy, Emergency Calling Policy, and Emergency Call Routing Policy. Note that these policies can also be user-assigned and have Global/Default policies. These site-assigned policies exist because users may work from multiple sites, and for these three policies it makes sense to have them be site-assigned. A site-assigned policy takes precedence over a user-assigned policy and a global policy.

Let’s consider the Network roaming policy. You might be familiar with the term “call admission control”, that’s what’s happening here:

There are just two settings here. One is to allow Video conferencing – or to turn video off. The other is to set a maximum bit rate. The bit rate setting has an info icon beside it that is informative:

A bitrate entered here will affect audio and video, including video content shared in meetings. When a network roaming policy is applied to a site, it applies to every user present in that site. Each user may use up to the bit rate specified in the policy – this is not a “per site” restriction, it is a “per user at this site” restriction.

The idea behind this policy is that if you have a network site with low available bandwidth, you can restrict the amount that a Teams user’s audio and video can consume when they “roam” to that site. This will scale back resolution, refresh rate, video features, and codecs selected to stay under the cap. When a user “roams” to a different site, this policy no longer applies.

Like other policies, their is a Global policy. You shouldn’t modify this unless your entire network has terribly low available bandwidth. You can also assign a policy to a user, causing it to always take effect. There’s no practical reason that I can think of to do this outside of perhaps an April Fools prank. Nonetheless, it follows the same model as any other policy.

The Emergency Calling Policy and Emergency Call Routing Policy are where you configure various options for handling emergency calls. How you want these handled will most often be different for each site. Global and site assigned policies are both valid here, and commonly used together. Global policies act as a “catch all” for remote users, or in the event of a misconfiguration of the bits that establish which site a Teams device is in. In some cases it may be possible to use just Global policies here. It would be very rare to assign these policies directly to users. There is a requirement for that with certain shared calling configurations.

To summarize this first section, policies can be assigned Globally, to a site in certain cases, or directly to a user. Policies assigned to a site will take precedence over those assigned to a user, which in turn take precedence over a global policy.

But wait, there’s more!

With just these options, it could be painful to administer policy assignments. Imagine yourself as the Teams admin responsible for policies in a global organization with 50,000 users. You would invariably have different policies for different regions and groups of users. It would be ugly to have to assign policies directly to every single user!

There are two ways of making this easier. The first is Policy Packages. These are a “bundle” of policies that can be assigned versus the individual policies. This helps keep all of the users who need a set of policies aligned with the same policies. I see policy packages used extensively in education and healthcare. Microsoft has a number of policy packages pre-defined:

The second way of making things easier is with Group Assigned Policies. Instead of assigning policies directly to a user, policies can instead be assigned to a group. Members of that group then receive the policy.

There’s an issue that needs to be addressed with this concept, and that is “what happens when a user is in multiple groups with conflicting policies”. The answer is simple, the list of group assigned policies is ranked, and the highest-priority/lowest-numbered one is what is assigned. This can get a bit messy when your list of policies grows large. Good naming standards are helpful here.

When you view a policy, you can see if it is assigned to groups. There’s a tab here where you create the group policy assignment.

Now if you’re really cool, you’ll use groups to assign policy packages!

Drop me a comment if there’s an area of Teams policies that you’d like me to cover in more depth.

In my last post I talked about changing the “organization name” reflected in an emergency address. If you try to do this in Teams Admin Center, you’ll run into a brick wall:

Note the little “Why can’t I change this address?” at the bottom. Well,  the good news is that you can indeed change it, but you need to use PowerShell.

First, head back to the Emergency Addresses page in Teams Admin Center and make note of the Location ID

We don’t want to modify the Location, we want to modify the Emergency Address. However, the Civic Address ID that represents the emergency address is no longer displayed in TAC. So, we’ll connect some dots in PowerShell to get what we’re after.

Now we have our CivicAddressID and can use that to view our Emergency Address/Civic Address

And here we can see our Organization Name/Company Name (sooo many things with different names in TAC vs PowerShell vs M365 Admin Center…)

Now, we want to ensure we’re making changes to the correct object. So hit the up arrow and edit that get- command to be a set- command, and add -CompanyName and the new name string

Triple check you have the correct Civic Address ID, then hit enter. Success!

And we see the same in TAC

You can use the same process to change most of the other fields that you see when you did the Get-CsOnlineLisCivicAddress. This is great for fixing typos, updating addresses or names, or just tweaking capitalization in spots because not having everything is painful to you.

It took me more than a few minutes to come up with that title, and I still don’t think it says what I want it to. Hopefully search engines piece things together for everyone!

A new feature has snuck out to the Microsoft 365 Admin Center. It’s not a big one, but it sure is a useful one. If you add a Calling Plan license to a user, you will now have the ability to assign a phone number to that user, right in M365 Admin Center.

You can also acquire a new number if you need to, and further, you can create a new emergency address if this is the first number for a location.

This is awesome, I think it cuts out a couple thousand mouse clicks through Teams Admin Center to accomplish the same task. It’s even better when licensing multiple users.

Here’s this new feature in action. In this scenario, I need a phone number for a new location so I need to also create a new emergency address.

The first step is to license the user. In this case, adding a PAYG Calling Plan:

Once that’s done, we get a yellow caution bar advising that they can’t yet make or receive calls. I wish the button on the right used the same language as the text “set up their phone number” vs “assign their phone number”. In any case, click the “Assign phone number” button.

Now we can either select an existing emergency address using the drop down, or we can select Add a new address. Let’s add a new one.

First, let’s clear up what an emergency address is. It’s really two things here.

One, Microsoft is you phone company, and it’s a requirement that every number have a static “emergency address”, sometimes referred to as a “service address”. This is not the address that the bill is sent to, aka the billing address. And of course, Teams is capable of dynamic emergency calling, where the location of the device placing the emergency call is reported instead of this static address.

Two, Microsoft needs to know what area code and city to select phone numbers from, either numbers that you already have or new numbers.

Here are the fields that you need to complete, and one optional field.

The “Place name or description” isn’t very well described here. Typically this would be a suite or unit number, such as “Suite 1601”. It could also be something like “Council Chambers” or “Electrical room”. It’s the “dispatchable location” that tells the emergency services where to go once they’ve pulled up to the front door. You should only leave this blank if the address provides all of the details needed to reach the location of the caller, such as a small building with just one company in it.

Like this:

Now you need to add the latitude and longitude. This help remove ambiguous things that come up with addresses, like “1501 West Street, North East Edmonton”.

Click Confirm address and then review everything on the next screen. Now you’re offered a phone number to assign to the user. My tenant didn’t have any numbers from that location, so Microsoft is offering one here, they’d held it for 15 minutes. Note that you don’t get to pick your number from Microsoft. If you really, truly need a certain number, your best bet is to acquire it through an existing telco – possibly a mobile provider – and then port it to Microsoft. (But honestly, that’s pretty 1998, isn’t it?)

Hit Finish assigning, and you’re done!

Here’s something to watch for with the process of creating a new Emergency address in this process. If you look at the address in Teams Admin Center after it’s created, you’ll see this:

Notice the organization name. It’s important here as it is included as part of the address information provided to first responders. My recommendation is that the “Organization name” here reflect what on your signage. “Tom’s Towing” is good, “81563534 Canada Ltd” is not so useful.

In this case, it’s picked my tenant name and all is well. However, if you organization has a tenant name that doesn’t reflect your organization’s name, you’ll need to head to PowerShell and change that. For example, I’ve seen things like “TimsTrucks” as an tenant name, but the organization is now “Smith Logistics”.

And lastly, if you’re the person in charge of your emergency addresses, you’ll want to keep an eye out for new ones popping up. Do some periodic cleanup to get rid of incorrect or unused addresses. Do some investigation and find out why 9999 Columbia Street showed up, when that’s actually not the address of your buiding in that city.

Should an organization need to deploy QoS in their environment for Teams, you’ll need to push settings out to your clients. Intune is the way to go, unless you’re still in the Active Directory phase of things and using Group Policy.

Well, there’s no point in me explaining how to do this, as Edgar Avellan has already done everything:

https://github.com/eavellan/intune-teams-qos-deploy

Now, a couple of caveats. First, I’ve long been a fan of NOT configuring QoS unless you are having call quality issues and can see issues in the Call Quality Dashboard or your network gear. Why not?

• Most modern networks have more than enough bandwidth. QoS only helps when their is congestion.
• There’s no QoS on the Internet. Only on your LAN/WAN.
• You need to control the endpoint – byod devices won’t get prioritized
  • Okay, not 100% true. You could have your network gear mark traffic based on the source port number. However, this WILL lead to non-Teams traffic being marked. Marking the traffic on the client usually means that you can specific the executable name “ms-teams.exe” to avoid this. You will, however, need to use this approach to classify and tag traffic that isn’t generated from your managed endpoints:

• Do you have a plan for your wifi? How much of your traffic in your offices is connected wirelessly vs wired?
• Do you have a plan for marking inbound traffic? You need a firewall – or a router just past it – that can apply DSCP tags, as the traffic inbound from the Internet won’t have them. Otherwise, you’re only tagging outbound traffic.
• What about non-Windows devices: web clients, Mac clients, and smart phones? Do you have control over these devices, and the ability to manage and monitor?
• How about VPNs, SASE, ZTNA? What impact do they have on your DSCP markings? Do you enforce “always on”, so that traffic from a machine on your LAN in your office is immediately tunnelled out to the VPN/SASE/ETC device, even if it you’re communicating with someone who is also on your LAN in one of your offices?

If you’re thinking of doing QoS, your first step is to find evidence that says you need to do it (and user complaints about bad calls aren’t sufficient here). Then, plan, plan, plan, plan! Implementation and operations are significantly bigger that they appear at first glance.

When you’re configuring a SIP trunk to an SBC, there are a couple of network setup steps that you’ll need to implement to prevent pain and suffering down the road. That pain and suffering might be “just doesn’t work” or it could be “intermittent interruptions”.

If your SBC is behind a firewall, you’ll need to ensure that firewall isn’t killing things that it shouldn’t. This means turning off “deep packet inspection”, “SIP Session Helpers”, and “Application Layer Gateways”. The last two are really meant for SIP phones outside the firewall accessing a PBX inside the firewall. They can (and do) work well for that. Deep packet inspection has two main challenges. First, every major firewall that I’ve met is too dumb to understand SIP, and it breaks things. Second, it adds latency to real-time communications. That may not be an issue if everything else in the network path is adding minimal latency, but it can add enough to be a problem.

The solution here is to disable this functionality, and to use the IP addresses and ports associated with the SBC and SIP trunk provider to allow or deny traffic. (You should be doing this anyway – don’t depend on your cool, smart firewall when you can just outright block a ton of potential issues by IP address allow/deny).

If you are a security person and you’re freaking out over this outlandish proposal and insisting that you be able to deep scan everything, take a minute here to consider this: The SBC is a better SIP security device that your firewall will ever be. SIP security is part of its job! The carrier you are connecting to is very interested in the security of their end of that connection, as the most likely security issue is a bad actor making use of their SIP services for free.

Next, let’s talk NAT. Your firewall is likely translating your internal address space (10.10.10.27 for example) to a public IP assigned by your ISP (203.0.113.12 for example). This changes the “outside” of the IP packets, but doesn’t touch anything inside the packets. That’s fine for most things, but it can really break SIP.

The inside of a SIP packet has IP address information contained in it, too – that 10.10.10.27 is there. However, the SIP provider you’re passing this packet along to can’t access that, it is an internal IP range on your network (and since I used a popular range in this example, likely on many other networks too). The IP address inside the packet must also be translated to 203.0.113.12.

This is what firewalls are terrible at. They don’t speak SIP, they don’t know how to do this. SIP Session Helpers and Application Layer Gateways can take care of this for Internet endpoints accessing an internal PBX, but fail miserably on SIP trunks.

Good news, however. Your SBC has the capability to deal with this problem. There’s a field in the NAT configuration of your SBC for you to input the public IP (203.0.113.12) that your firewall will translate its traffic into. The SBC will send packets with the 10.10.10.27 replaced with 203.0.113.12 inside the packet. It leaves the 10.10.10.27 in place on the outside, however, as this is needed for the internal network path from your SBC to your firewall, which then translates this part.

There are a handful of license types for Microsoft Teams voice functionality. This seems painful, but really, it’s to your benefit – the licenses are “bundles” of features that you need for a specific function: user, auto attendant, shared lunchroom phone, etc. So, let’s dive in.

Throughout, I’ll use the full name “Microsoft Teams Room Pro” that you’d expect to see in the licensing tab of M365 Admin Center. I don’t stick formal names, but it feels like I should here if helping you find the right license.

Update: some name changes (surprise!) so I’ve updated this post.
Update2: Where you see “E5”, that same bit applies to E7.

Microsoft Teams Phone Standard

This one used to be Cloud PBX, then Phone System. It’s what gives your Teams client a dial pad, the ability to dial out and receive calls from the PBX, and a bunch of functions you’d find in a phone system – caller ID, hold music, transfer, etc. Without this license, you can only do Teams-to-Teams voice chats and meetings.

This license is included in a number of “bundles” that I spoke of. It is included in E5/A5/G5, Shared Space, Resource Account, Microsoft Teams Rooms Pro. It is not included in E3/A3/G3 and below. If you’re running 3’s as your main license and adding Teams voice functionality, it might be time to consider bumping up to 5 (and 7!).

Calling Plans

These are really a family of licenses, they get you a phone number and dial tone from Microsoft. That last bit is important. This is “Microsoft the telco, like AT&T”, not “Microsoft the company that wrote Teams”. I’m not saying here that Microsoft is two companies, I’m only trying to demonstrate that Calling Plans are a “telco” thing and not a “Teams software” thing. Calling plans come in “minutes per user/month/country”, as well as pay as you go.

If you are using Operator Connect or Direct Routing, you do not need anything in the Calling Plan family of licenses.

Microsoft Teams Shared Space

These used to be called Shared Device, and CAP or Common Area Phone before that. From the voice perspective, this is a phone that isn’t assigned to a user. Rather, it’s assigned to a place or a role, eg “Lunch Room”, “Reception Courtesy”, “Duty Chief”. It also applies to a host of other things, mostly around Microsoft Places.

Microsoft Teams Phone Resource Account

This license solves the problem of “I have an Auto Attendant, how do I assign it a phone number so people can call it? And how do I assign it a UPN so that my Teams users can click-to-call it in a Teams-to-Teams call”. Think of this as a special type of user license that is severely restricted. It can’t actually log on, it doesn’t get a mailbox or SharePoint or Intune or whatever. The sole purpose of a resource accounts is to plug a phone number and UPN into your auto attendant (or call queue, or other custom voice app) – nothing more.

A resource account is based on a user account. Microsoft had a choice: copy the user account code and massively customize it to do everything a resource account needs without a license, or craft a purpose-built license that takes care of that, without requiring the rewrite. They chose the latter. That license is the Microsoft Teams Resource Account license. It is the ONLY license that you should assign to a resource account other than adding something from the Calling Plan family, should you be using Microsoft Calling Plans for your dial tone & phone numbers. In Teams Admin Center, resource accounts have their own section apart from users. In PowerShell, you’ll mostly use “user” commandlets.

And on the plus side? The license is completely free. You obtain it the same way you do any other license, but it’s $0. You need one of these for each phone number or UPN that you want to use to enable an auto attendant, call queue, or voice app to receive phone calls. (Note: if you have an auto attendant that forwards the caller off to a call queue, but you do not want that call queue to be called directly, you need only license the auto attendant. The call queue cannot be called directly, nor does it appear in the directory in Teams).

Microsoft Teams Audio Conferencing

This license allows the user to create a Teams meeting that allows dial-in capabilities. This is old school dial-in to a conference bridge. Those who dial in do not require this license, only the meeting organizer. It also allows dial out from the meeting to a phone number to add them to the meeting. This is an add-on, but it feels like it’s bundled with an awful lot of other licenses.

Did I miss anything? Hit me up in the comments if you’d like me to add or clarify something.

They’re the same

No, they’re not, and yes this is the first time I’ve started a post with a meme.

What am I talking about? I was working with a customer recently who needed to configure Teams to play something other than the “spa tunes” default hold music. In particular, the scenario was a call that comes to a call queue, is answered by an agent, and is then transferred elsewhere.

Here’s the Call Queue “Greeting and music” configuration with “Music on hold”:

And here’s the Call hold settings, with hold music:

And looking at these two screenshots, it’s not immediately clear what music/audio file (it doesn’t have to be music!) applies where/when.

Here’s the flow. When the caller first hits the Call Queue, they will hear the “Greeting” in its entirety. Then, they are placed into the queue and will hear the “Music on hold” while agents’ phones ring. Once the agent answers and begins the transfer process, the audio file from the “Call hold section” comes into play. That’s because the first part of a call transfer is to put the caller on hold.

If the Call Queue settings page referred instead to “queue wait music” and the Call hold settings referred to “hold music”, I think this would be clearer. It could also be helpful if there were info/tips on each page that explain when that music/file would be played.

Teams emergency call notifications meet all of the requirements of Kari’s Law, but they’re not super flexible. Microsoft received a bunch of feedback on this, and have a great solution.

At the most basic level of notification, you send a Teams chat message to a group of people. You can then layer on conferencing those same people into the emergency call, with or without the ability to unmute themselves. The users conferenced into the emergency call are the same list of users who receive the text notification, which isn’t great in some circumstances. For example, I would like to notify the intern sitting at the reception desk that an emergency call has been placed, but I would not want to conference them into a live emergency call. Anyone being conferenced in should be in the security department or similar, and not more “pedestrian” roles in the organization.

I recommend against allowing the ability to unmute, in most circumstances. The very last thing that a busy emergency call taker wants/needs is somebody unexpected talking over them as they’re trying to get the right response rolling. Unmute may be beneficial to a well-trained group of people who know to use it very selectively. The rest of us can just call 911 from a different phone, talk to a different call taker, and provide any additional information.

There’s also the option to conference in just one external phone number (which can also be just one internal number), with no method for them to unmute. This is a good option for a security desk where the staff don’t have Teams clients, or for a mobile phone.

For a more complex scenario – chat message to these people, email to these other people, conference in these Teams users, flash a light – there was no option in Teams that supported them. If an organization was using Direct Routing, some emergency service providers could offer additional services, and some people figured out how to have SBCs trigger a web hook when an emergency call was placed.

Microsoft has recently announced a preview of Graph API, with details available here. This API will provide the same information that Teams provides in its notifications, as well as to emergency services. As I become aware of services and apps that can consume this information, I’ll add their details to this post.

It is not an “either/or” choice of using the API or notifications built into Teams. You can easily configure both, using Teams for basic notifications, and the Graph API (and supporting applications) for richer flexibility.

Update on April 18 2025: Check out this demo video of ecall desktop notifier from Entergrade

If you have multiple SBCs (and trunks) in your Direct Routing deployment, you may have a scenario where a call comes in one trunk and then is automatically redirected out a different trunk by an Auto Attendant or Call Queue.

This could be because the destination is in a different country or rate center and you want to avoid long distance charges. I’ve also seen this in scenarios where a call comes in from the PSTN but then needs to be forwarded out a different trunk to a PBX or contact center, typically with an extension or private number that can be routed via the PSTN.

Resource Accounts that are under the hood of call queues and auto attendants need to have a voice routing policy assigned to them in order to send calls out a direct routing trunk. If that voice routing policy contains the SBC that was used for the inbound call, that SBC will automatically be selected for the outbound call, regardless of any priorities that you configure. If everything is configured properly, a REFER message will have the SBC (or something further upstream!) handle the forward and remove Teams from this loop.

However, if you need the call that came in via the first SBC to egress via the second SBC, you will need to create a voice routing policy that uses the second SBC and does NOT contain the first SBC. This voice routing policy gets assigned to the resource account for the call queue or auto attendant that is doing the forwarding.

If you are in a scenario where you have an auto attendant that is doing forwarding to numbers that must be reached via both of the SBCs, you will need to have one of the SBCs involved, or you’ll need configure the SBCs to route between each other and have Teams configured for direct routing to only the main SBC. Ideally, this would be your configuration anyway – Teams is not an SBC or session manager and should only be used as a last (hopefully temporary!) resort for oddball routing scenarios like this.

Failing that approach, you may be able to have the auto attendant or call forward to a Teams user and have that user set to call forward via the second SBC. You will need to test this, it’s entirely possible that there is/was something in my lab configuration and/or Teams call routing when I configured this, that does not apply to your scenario.

Teams Auto Attendants have a scheduling feature, which includes providing alternate call handling options during holidays. This isn’t well explained, and the flow within Teams Admin Center isn’t…. flowy. Once you understand a couple of key nuances, lightbulbs start going off.

If we have an Auto Attendant (AA) called “BumpinTheNetHQ” and want to setup Christmas and New Years holidays, we’ll see something like this in TAC:

Now if we click “+Add” we are prompted for a name for our holiday call setting, a spot to pick a Holiday, and then call handling things like a greeting and where to route/how to handle the call:

For the name of you holiday call setting, you should make it descriptive. In this case, I’m building the call flow for Christmas. I’ve included the “call flow” bit rather than just calling this Christmas, as I find it helps me keep all of the various uses of “Christmas” straight – especially if I’m working in PowerShell.

Note that you CAN edit this name, which is fantastic for tidying up to keep things a bit more understandable.

Here I’ve also assigned a “Holiday” called Christmas (more on that later!) and I’ve configured the Auto Attendant to speak “Ba Humbug!” before disconnecting the caller:

And if I click save, I am back at the Holiday call settings page:

I can click +Add and configure a New Years call flow as well:

Giving me this for Holiday Call Settings:

And this is “later”, so let’s talk about this Holiday drop down:

When you’re using this dropdown, you are presented with a list of ALL holidays configured in your Teams tenant, as well as an option to create a new Holiday:

Note that I’ve got the name of my Auto Attendant at the front of the Holiday name. That’s important to have as your different Auto Attendants for different departments may all have different schedules for the same holiday.

You can better administer Holidays through the Holiday section of the Voice menu on the left menu. Here we can see a list of all of the Holidays configured in Teams, plus the start of the dates that are configured for that Holiday. Note that you don’t get to see times here, and a long list of Holiday Dates may not fit on your screen.

Note that you CAN rename Holidays, just as with call settings.

We haven’t talked about times yet, or about multiple dates for a Holiday, so clicking on BumpinTheNetHQ Christmas gets us this:

I’ve defined Christmas for two years here, and I’ve also fiddled with the start time for Christmas 2024. If your organization (or department) closes early on Christmas eve, you could set the start time to 12/24/2024 and 2:00pm, for example. You can also cheat ahead and configure multiple years’ worth of holidays. Just be sure to put a reminder in your admin schedule/runbook/Outlook/whatever so that you remember to come back and update them (unless you plan on winning the lottery before they run out, in which case it’s not your problem!)

Eagle-eyed readers will have spotted the “BumpinTheNetHQ All Holidays” Holiday. Above, we have different call handling for our Christmas (Ba Humbug!) and New Years (the countdown message) Holidays. This is very flexible for different greetings and handling if that’s desired for your Holidays. However, if you don’t differentiate between Holidays with how they’re handled – say you just play a “we’re closed for the holiday, please leave a message and we’ll get back to you” greeting and dump the caller into voicemail for every Holiday – you would wind up having to manually duplicate (or dive into PowerShell) all of your call flow options. I’m using simple greetings and “disconnect” as an example here, but if you have a number of options “Press 1 for xxx, Press 2 for yyy…” that’s a lot of work to create and maintain.

Instead, you can build something like the “BumpInTheNet All Holidays” Holiday:

And use that with your single holiday call setting. Here we’ll just unceremoniously disconnect all callers on the above holidays:

The downside to this approach is that there is no description for each of the day/time entries in the Holiday. Some are obvious, some aren’t, especially if you are an international or multicultural organization.

Let’s just back to the “BumpIntheNetHQ” prefix on all of my holidays to reinforce that – every Auto Attendant will have an option to pick any existing Holiday that’s defined in a tenant. Starting the name of the Holiday with the name of the Auto Attendant that it applies to, or the department or team or whatever if there are multiple AAs that share the same exact Holiday set, will prevent a lot of grief.

If you’re just starting out with your Teams deployment, please spend some time building out a couple of Auto Attendants with a bunch of different Holiday structures so that you can understand how they work before you start deploying. You don’t need a phone number to call an Auto Attendant, you can call by name. You also don’t need to play a bunch of different menu options (unless you’re exploring those) – keep it simple and play a silly fun message to let you know where you wound up, and then just disconnect the call.

If you’re a visual/flow-chart type of person, here’s a visual of how these bits connect:

Or if you prefer the “one Holiday call settings, many Holiday date/time entries” approach: