When configuring call flows in Microsoft Teams, one question I hear a lot is if a call can be forwarded to multiple external numbers at the same time.

This most likely applies to after-hours on-call scenarios where it’s absolutely crucial that somebody will eventually answer the call.

Currently, this is impossible with Teams call queues. However, this is by design. The purpose of a queue is that the call stays within the queue and the company has control over the call for the entire flow of the call. In other words, the queue makes sure that the call stays within company boundaries by ignoring all user configured call answering rules. So, if a user has configured his calls to immediately forward to a personal cell phone, the queue simply doesn’t care and will present the call to the user in Teams anyway.

If you must forward the call to multiple numbers at the same time, you can use regular Teams (Microsoft 365) users. I always suggest using dedicated, generic accounts for this, even though it’s an additional license cost. This will make management easier and ensures that no user is able to change the forwarding settings and mess with the call flow on their own.

Since I did this in my lab, I used the users I already had to demonstrate this. This means that they have real sounding names and are not generically named accounts like I would use in a real-world scenario.

How To Configure It

To configure forwarding to multiple external numbers simultaneously, identify where in your auto attendant or call queue the call must be forwarded.

Next, think about to how many numbers the call must be forwarded. Create one Teams enterprise voice enabled user for each external target number. Then create one more Teams voice enabled user. On this user, configure a call group and add all the users which forward to external numbers immediately.

Set this user’s call forwarding settings to either immediately forward to or also ring the call group.

The accounts which are members of the call group must all be configured like this.

While the first user can be configured to either also ring or immediately forward to the call group, the call group members must be configured to immediately forward. If they’re set to also ring to an external number, it will not work.

Call Flow Diagram

I updated the M365 Call Flow Visualizer and added two new parameters.

-ShowNestedUserCallGroups  
    Specifies if call groups of users should be expanded and included into the diagram.  
    Required:           false  
    Type:               boolean  
    Default value:      false  

-ShowNestedUserDelegates  
    Specifies if delegates s of users should be expanded and included into the diagram.  
    Required:           false  
    Type:               boolean  
    Default value:      false

This allows us to indefinitely expand and display the user calling settings of call group members and delegates in the diagrams as well.

Please note that these features are currently only available in the DEV branch of the GitHub repo. I did my best to thoroughly test this but since there are basically unlimited possibilities of how users are interlinked within user call groups and delegates this is quite hard. There may still be some bugs, if you encounter any, please let me know.

Other Options

This also works if you use call delegation instead of a call group with both immediately forward and also ring on the first user. I tested it with Microsoft Calling Plans, but it should work with Direct Routing or Operator Connect as well. The maximum amount of simultaneous external forwards via call group I tested was three and that still worked as expected.

I recommend using a call group over delegates because this gives you a little more flexibility. While delegates will always simultaneously ring all delegates, a call group can be configured for serial ring as well. In this case, it will always ring for 20 seconds per call group member before the next one is tried. This time out cannot be changed as of today.

Caveats

When you do this, you need to be aware of issues that might occur. At the beginning of this article, I briefly mentioned that the purpose of a queue is to stay in control of the call for the entire time. That’s not the case when using external forwarding on user calling settings. For example, if one of the external targets is not reachable by e.g. having a rather short voicemail timeout, is in flight mode or just has no reception, calls might get lost on personal voicemail boxes outside of a company’s control. Once a call hits any voicemail box, the call is technically connected and will stop ringing the other targets, even if parallel ringing is configured on the call group. This also applies to call groups configured in serial ring. If e.g. the first target is not reachable, and the call goes to voicemail the other targets won’t even be tried anymore.

It’s also noteworthy that user configured calling settings can become extremely complex and it’s easy for users (or admins for that matter) to build loops or enable forwards without knowing about it.

The same goes for the M365 Call Flow Visualizer, I don’t think that it’s possible to accurately display everything that’s configured in nested user calling settings. I tried my best to render call flows where a serial ring is configured on a user configured call group though. As an example, I configured the same call group which was already shown in the above diagram for serial ring. Now all the call group targets are displayed in chronological order, and you can see how the call trickles down to the next target after 20 seconds.

Unlike with call queues and auto attendants, where the M365 Call Flow Visualizer does a fantastic job displaying things as they are, please take complicated nested user call groups and delegate flows with a grain of salt. At least for now.

Look at this call flow for example. When the call gets to Bill Stearn it will also ring his call group in serial order. Thus, it will ring the mobile number +4178857**** for 20 seconds. Because there is an unanswered timeout of 20s configured for Bill the call will then be forwarded to his delegates where the call will be forwarded to Bobby and Mike and they have an immediate forwarding configured to their mobiles.

All the users who are members of the call group are linked after each other because the call group is configured in serial ring. The links which point from the delegate sub graph (which is always parallel ring) to the delegate users are still linked to the correct user but it’s not very easy to understand what’s going on.

When we think about the delegate flow, the chaining from Bobby’s time out of 20s doesn’t actually apply anymore and the call won’t be forwarded to Mike because that part of the diagram only applies to the serial order of Bill’s call group.

Last but not least, Wendy is also included in the call flow even though a call could never go this far in that specific call flow because of the applied time outs.

Unfortunately, I currently don’t see any way I could solve this with the visualizer script.

I’d like to point out that configuring both a call group and delegates on the same user seems extremely unlikely and is something I would generally refrain from.

Conclusion

Although it’s not an ideal solution, using generic user accounts and call groups for certain scenarios is for sure a creative one. In some cases, this might help you solve a very specific niche scenario which previously seemed impossible.

I do recommend using auto attendants and call queues to build your call flows whenever possible. If you must use call groups, I advise you to keep it simple and create generic accounts to which only Teams admins have access to. Otherwise, it’s free-for-all kind of situation and users can mess with your configuration as they please.

If you stick with simple scenarios (like shown in the first three diagrams in this article) and avoid building call group loops or timeouts which cancel each other out, I don’t see any issues why you shouldn’t do this if you really need to.