In December 2024 Microsoft made a change to their auto attendant and call queue service allowing admins to build call flows without associating a resource account to every nested voice app (call queues and auto attendants). Top-level auto attendants or call queues which are directly called by a phone number still need a resource account associated with them though.

When I wanted to create some diagrams of newly configured call flows using my M365 Call Flow Visualizer tool, I noticed that I got Mermaid syntax errors and that the diagrams weren’t displaying anymore. This was because the newly built call flows were already referencing the voice apps directly and not the resource accounts anymore.

How does it look in PowerShell?

Let’s look at some examples. This is an auto attendant which I haven’t touched in years. It’s a simple demo attendant which has a voice menu where different keys will transfer to two different auto attendants.

When I check this attendant in PowerShell, I can see that the CallTarget type is ApplicationEndpoint which means it points to a resource account (Online Application Instance).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

PS E:\GitHub\heusser-pro-v2> $aa = Get-CsAutoAttendant -Identity 9516a748-95e5-4024-aae1-5f11fad27a52
PS E:\GitHub\heusser-pro-v2> $aa.DefaultCallFlow.Menu.MenuOptions

Action         : TransferCallToTarget
DtmfResponse   : Tone1
VoiceResponses : {}
CallTarget     : Type = ApplicationEndpoint
                 Id = 0ae17201-09fb-4434-ac7b-66681fb34345
Prompt         : 

Action         : TransferCallToTarget
DtmfResponse   : Tone2
VoiceResponses : {}
CallTarget     : Type = ApplicationEndpoint
                 Id = 1ba43d85-20c8-41bf-a474-9b771877b4be
Prompt         : 

Action         : TransferCallToTarget
DtmfResponse   : Tone3
VoiceResponses : {}
CallTarget     : Type = ExternalPstn
                 Id = tel:+496971041xxxx
Prompt         : 

In TAC, we now have a new option called Resource Account next to the existing Voice App option. This way, we can choose if we want to forward calls to a resource account associated with a voice app or to a voice app directly.

This is actually a bit confusing to me. As I recall, the option to transfer to another attendant or queue was always called Voice app before but it was actually referencing resource accounts. I checked one of my previous blog posts and found this screenshot where it’s clearly visible that the Voice app is in fact referencing a the UPN of a resource account.

When we look at the voice menu in TAC again after the change, we can see that the existing options which previously said Voice app are now called Resource account. I’ve replaced the third menu option with a Voice App now.

So, existing configs referencing resource accounts that were previously labeled Voice app are now called Resource accounts and if you want to reference a voice app, you’ll need to select Voice app.

Let’s look at the PowerShell output again. Notice how the third option now says ConfigurationEndpoint and not ApplicationEndpoint anymore. Both options are valid configurations and can be mixed and matched as you need but it’s important to understand the difference.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

PS E:\GitHub\heusser-pro-v2> $aa = Get-CsAutoAttendant -Identity 9516a748-95e5-4024-aae1-5f11fad27a52
PS E:\GitHub\heusser-pro-v2> $aa.DefaultCallFlow.Menu.MenuOptions

Action         : TransferCallToTarget
DtmfResponse   : Tone1
VoiceResponses : {}
CallTarget     : Type = ApplicationEndpoint
                 Id = 0ae17201-09fb-4434-ac7b-66681fb34345
Prompt         : 

Action         : TransferCallToTarget
DtmfResponse   : Tone2
VoiceResponses : {}
CallTarget     : Type = ApplicationEndpoint
                 Id = 1ba43d85-20c8-41bf-a474-9b771877b4be
Prompt         : 

Action         : TransferCallToTarget
DtmfResponse   : Tone3
VoiceResponses : {}
CallTarget     : Type = ConfigurationEndpoint
                 Id = 82c392e9-ec73-4890-bc5e-99d385f935b9
Prompt         : 

Updated M365 Call Flow Visualizer

I’ve updated the M365 Call Flow Visualizer to support nested voice apps which don’t have associated resource accounts anymore.

The visualizer has always only shown an auto attendant or a call queue as a node element, regardless of which resource account was linked, it’s still the same in the current version. As you can see in the diagram above, both the keys 2 and 3 point to the same auto attendant even though one menu option is referencing the resource account and the other one is referencing the auto attendant directly (voice app).

Additional Notes

Even though the functionality to link voice apps without resource accounts have been added to TAC already, it will still display a warning that all voice apps must have an associated resource account.

Call flows which don’t have any resource accounts associated with them, are not supported in historical reports yet. Availability for this is expected in early 2025 according to this LinkedIn post.

From what I can see, auto attendants or call queues will not show up in Teams search either because there is no user account object to search for.

Version Notes

If you’re already making use of this new capability, make sure to pull the repo or download the latest version to be able to generate diagrams for these new call flows. You’ll need version 3.1.9. This version also fixes and issue where an inbound number was shown multiple times in case a nested voice app looped back to the initial top-level voice app. A full change log can be found here.

When I wrote this blog, I didn’t think about writing additional code to reflect in the diagram if a TransferCallToTarget or TransferCallToOperator action is transferring to a voice app or a resource account. However, the longer I thought about it, the more sense it made. I’ve already got a new version (3.2.0) ready for your to try in my dev branch on GitHub.

Here’s a wild example. As you can see, each TransferCallToTarget node which goes to either an auto attendant or a call queue now shows if it’s transferring to a resource account or the voice app itself.

As you can imagine, maintaining the code and keeping up with Microsoft’s changes takes up a lot of my spare time. If you want to support me, you can do that here.