A few weeks ago, Microsoft published a message center post about allowing authorised users to make changes to Teams Call Queues and Auto Attendants.
Seemed like a very nice feature and I was hoping this would cover things like changing agent membership of Call Queues as for those teams that work in shift patterns they regularly need to change who's in or out of a queue. They could add everyone and then use the "opt in/out" toggle but that's prone to users forgetting when they log off and for teams where they have a high turnover of staff they might be adding or removing users entirely on a regular basis. Having to raise a support ticket each time and the lead times on an admin then making the changes is cumbersome and time impacting.
Having read through the Microsoft documentation, the initial release of this feature doesn't include managing agent membership unfortunately (hopefully that'll come in a future release). Currently it only allows changes to be made to greetings and annoucements for Call Queues and Auto Attendants.
I noticed the other day that the Voice Application Policies blade had appeared in my dev tenant so I thought I'd have a look at how it works and what it looks like for the end user.
Microsoft have published some guidance already on how to set these up in preparation for when this is GA, here's the link: https://learn.microsoft.com/en-us/microsoftteams/manage-voice-applications-policies
Setting up the Voice Application Policy
First thing we need to do is create a Voice Application Policy to define what actions the authorised users can carry out on the Call Queues/Auto Attendants that they are added to as an authoried user.
In Teams Admin Centre, under the Voice menu, click on Voice Applications Policies (should be last one)
Click Add, add a name for the policy and a description that will help anyone viewing what it's for etc.
The next section is where we define what this policy allows users assigned it can do. Toggle on the options you want to allow, example below.
This one I just want the assigned users to be able to edit the welcome greeting and music on hold for Call Queues and nothing else.
Hit Save and you'll see your new policy. We now need to assign to a user(s) to apply those permissions to them. Select the policy you've just created and click Assign Users, search for the user(s) you want to add, add them and then Apply. You'll get the standard "policies may take some time to take effect", confirm and that's now assigned.
All the above can be done using PowerShell as well using the X-CSTeamsVoiceApplicationPolicy cmdlets.
Adding Authorised Users to Call Queue
Now we've assigned the new policy to users, we need to add them to the Call Queue we want them to be able to manage.
From the Call Queue blade in Teams Admin Centre, edit the Call Queue you want them authorised for and you'll see a new section on the left hand side for Authorised users (I refuse to use the American spelling...)
Select this and then click Add, search for and select the user you want to add, then Add again.
You'll now see them listed as an authorised user.
Making changes as the user
That's all we need to to set it up from an admin perspective. Now to see how it looks and works as the end user in the Teams client.
Once you've done all the above it may take a little while for the client to have the policy and settings applied. Once it has synced though, the user can edit the settings we've allowed via the Calls section in Settings. Right at the bottom they should see the list of Call Queues/Auto Attendants they've been added to as an authorised user.
Clicking into that brings up the settings that the Voice Application Policy allows them to modify.
We can check that the current greeting message is aligned in Teams Admin Centre before we make any changes.
Back in the Teams client, as the user you can now amend that welcome message and then click Save.
I was interested to see how long any change would take to replicate up to Teams Admin Centre, and it was pretty quick. Within a minute or two, viewing the Call Queue there showed the updated welcome message. I imagine this might take a bit longer for larger tenants potentially but was nice to see anyway.
I haven't tested uploading a music file yet but can't see why it'd be any different. If you select an audio file in the Teams client you get a notification that it must be in MP3, WAV or WMA format and not be larger than 5MB.
Auditing Changes
The last part I wanted to look at was how you could audit these changes. I can imagine in larger environments where you may have a number of queues and multiple authroised users for a number of queues or individual ones you may get requests asking who made a change at a particular time/date. This might be for information or may be because an unintended/unauthorised change was made and you need to identify who made the change.
I can just imagine someone wanting to know who uploaded a Taylor Swift song as the Music on Hold music as it wasn't deemed appropriate ("I Knew You Were Trouble" would be a fantastic choice for people on hold!!)
After a little bit of digging I found you can see entries within the Defender Admin Portal although they are a little bit obscure. You can glean enough info from the log though to be confident it was a change via this method.
Within the Defender Admin Centre, navigate to Cloud Apps - Activity Log. From here, select Microsoft Teams as the App to search for and we're looking for an Activity Type of "TeamsAdminAction". This makes sense as if we were making this change as an admin this is exactly what it'd be. The feature to allow end users to do this basically just delegating this admin action to them via the policy.
The bit of info you'll need to then find the entry is the time/date the change was made. This may be tricky depending on when it was spotted as the window may be quite large. As we're viewing all Teams Admin Actions the list you have to sort through might be large so having a shorter time window to search will definitely help.
Once you have the date/time, you can search the entries. In my example that we carried out above, I can see an entry for 9:37 AM which matches up with when I made the change as the end user.
There may be a better way of searching for this particular action but I couldn't spot it easily.
To view the detail we need to look at to see the user who made the change, we need to click on the View Raw Data link in the Source property.
This will show us further detail and in the bottom half of this new window we can see the info we're after.
Two bits of info here we can see which help. We see the UserID shows us who made the change and then the second piece of info confirms it was a PUT action and lists the destination of the change, a call queue and the welcome greeting.
I knew this was the change I'd made but if you had a few entries at the same time how would you know this was the actual call queue in question. This tells me a user called Mark Webb made a change to a Call Queue Welcom Greeting but it doesn't tell me which exact Call Queue they made the change to.
I was fairly certain the identifier in the middle of the AdminActionDetail URI was it. Initially I thought that was probably the Object ID or App Instance ID of the Call Queue but when I queried that it wasn't.
Neither the ObjectiD or ApplicationID match with the entry above 78287c97-748c-42a1-b26a-38d8afb681f2.
I discovered the answer was in the Application Instance Association. Checking that for the resource account used on the Call Queue provided the match on the 78287c97-748c-42a1-b26a-38d8afb681f2 value.
This makes sense as we're querying the resource account, not the actual Call Queue. The resource account might be associated to different call queues over time so we need to see it's association to a Call Queue rather than the detail of the actual resource account.
So this info we have now allows us to be confident that we know it was the right Call Queue that was amended and we have the user name of the person who made the change.
Summary
Overall a nice feature from Microsoft, I hope they expand the capabilities of this to include more settings within Call Queues and Auto Attendants. That'll make it easier and quicker for users to update their queues and reduce the admin overhead to support desks which is a win win.
Comments