Getting Started with Teams Queues App: Features, Voice Application Policy Settings, and Roles

Welcome to the world of Microsoft Teams Queues App! This powerful tool is designed to streamline your team's communication and enhance productivity. In this post, we'll explore the key features of the Teams Queues App, including its intuitive interface and robust functionality. We'll also dive into the Voice Application policy settings and controls, which allow you to manage call routing and user permissions effectively. Additionally, we'll highlight the differences between a Teams Admin Role and the authorized user setting, ensuring you have a clear understanding of the distinct responsibilities and capabilities each role entails. Whether you're an admin or an authorized user, this guide will help you get familiar with the Teams Queues App and get started on the right foot.

Key features provided with Queues App 

Collaborative Calling: Teams working together to service customers can benefit from a shared call queue in a Teams Channel. This feature allows team members to manage calls collectively, ensuring that no customer call goes unanswered

Enhanced user interface: The Teams Queues App offers an intuitive and streamlined user interface, allowing team members to manage customer calls efficiently and enabling team leads to configure call queues and auto attendants directly from the Teams client, enhancing overall productivity and user experience

Real-Time Metrics and Historical Reporting: The app offers real-time metrics such as the number of waiting calls, average wait time, and longest call waiting time. Additionally, it provides historical metrics for call queues and auto attendants, helping teams analyze performance and make data-driven decisions

Enhanced Customer Engagement: By integrating with other Microsoft Teams features, the Queues App allows agents to quickly access subject matter experts within the organization. This immediate access to resources enables agents to resolve customer inquiries more efficiently, leading to improved customer experiences.

Seamless Integration: The app integrates seamlessly with Microsoft Teams, eliminating the need for agents to switch between multiple applications. This integration fosters real-time communication via chat, calls, and video meetings, enhancing collaboration and productivity

These features collectively help teams manage customer engagements more efficiently, streamline workflows, and ultimately enhance overall productivity.

Getting started with the Teams Queues App, there are several prerequisites you need to meet:

• Licensing: Users must have both a Teams Phone and a Teams Premium license. Once a user is licensed for Teams Premium, it can take up to 48 hours for the Queues App to be available in the Teams client. Queue agents can be a member of the queue without the Teams Premium license, but will not have access to the Queues App experience in Teams.
• Teams Preview Policy - at the time of this post, the Queues App is in Public Preview - review your tenant and user preview settings - Public preview in Microsoft Teams - Microsoft Teams | Microsoft Learn
• Resource Accounts: You need a Resource Account for each Call queue and Auto attendant. These accounts must have a Microsoft Teams Phone Resource Account license
• Admin Permissions: During deployment, a Teams Administrator account  is required to set up Voice Application policies, and authorized users of designated auto attendants and call queues.
• Teams Client: The Queues App is currently supported on Teams desktop and Mac clients, but not on web, mobile, or Virtualized Desktop Infrastructure (VDI) clients
• PowerShell Modules: As with many features and administrative controls, the queues app can be managed in Teams Admin Center or the updates Teams PowerShell module can be used.

Let's break down the differences between the Teams Admin Role and the Authorized User Policy settings for the Queues App and Voice Application Policies.

Teams Admin Role

Teams Admins have comprehensive control over the Teams environment, including the Queues App and Voice Application Policies. Their responsibilities include:

• Creating and Managing Policies: Admins can create, edit, and assign custom Voice Application Policies. These policies control what configuration changes authorized users can make to auto attendants and call queues.
• Full Access to Settings: Admins have full access to all settings related to call queues and auto attendants, including hours of operation, call routing, queue membership, and pre-recorded greetings.
• Delegation of Permissions: Admins can delegate certain permissions to authorized users, allowing them to manage specific aspects of call queues and auto attendants without needing full admin rights.
• Global Policy Management: Admins manage the global, org-wide default policy, which disables all configuration change capabilities for all users unless custom policies are created and assigned.

Authorized User Policy Settings

Authorized Users are designated by Teams Admins to manage specific aspects of call queues and auto attendants. Their capabilities include:

• Limited Configuration Changes: Authorized users can make configuration changes to the auto attendants and call queues they are authorized for. This includes managing business hours, call routing, and viewing real-time and historical metrics.
• No Admin Center Access: Authorized users do not need access to the Teams Admin Center portal nor do they need to be assigned any administrative roles.
• Access Through Teams Client: Authorized users can access and manage their assigned call queues and auto attendants directly through the Teams desktop client or the Queues App.
• Policy Assignment: Authorized users must be assigned a custom Voice Application Policy created by an admin. This policy provides the minimum levels of permissions needed for their role.

Key Differences

• Scope of Control: Teams Admins have full control over all settings and policies, while Authorized Users have limited control based on the permissions assigned to them.
• Access Level: Teams Admins access and manage settings through the Teams Admin Center, whereas Authorized Users manage their assigned settings through the Teams client or Queues App.
• Policy Creation and Assignment: Only Teams Admins can create and assign custom Voice Application Policies. Authorized Users can only operate within the confines of the policies assigned to them.

These distinctions ensure that while Teams Admins maintain overall control and security, Authorized Users can efficiently manage specific aspects of call queues and auto attendants, enhancing productivity and delegation within the organization.

Implementation Planning

We've covered the features and value within the Queues App. In getting started, there are a few recommended planning steps. 

• Assignment of the Teams Premium license - Teams Premium is required to access the queues application, while all queue agents may not require the Queues App interface, assign the Teams Premium add-on (not included in E5).
• App Setup Policy - define which users will see the Queues App and the pinned position of the Queues App (or user pinning allowed)
• Voice Application Policy - define the controls needed for each role or persona
• Authorized users - define non-administrative users who can interact, control and report within each auto attendant or call queue

Premium License Assignment

Teams App Setup Policy

Voice Application Policy

This section offers flexibility and should be planned accordingly. You may consider getting started with 3 policy settings based on persona's. 

• Manager/Supervisor
• Agent
• Reporting Only (no control or interaction with the call flow, visibility of statistics and reporting)

You may also consider additional policies here, and options to separate Auto Attendant functions from Call Queue functions. Often Call Queues are preceded in the call flow by Auto Attendants (nesting) therefor control of both functions may be needed.

Take note - the historical reporting options allow for control over ALL Queues in the tenant or only when authorized users are defined.

Auto attendant and Call queue historical reports - Microsoft Teams | Microsoft Learn

The Queues App interface provides access to real-time and historical reporting, keep in mind these settings also control access to historical reporting in Power BI

I covered this earlier this year in a blog post - Auto Attendant and Call Queue Historical Reporting in Power BI

Assign the policies to users

and

Define Authorized Users

Within each Auto Attendant and Call Queue - define the authorized users who do not have a Teams Administrative role.

As with any cloud solution - it may take time for licenses and policies to propagate down to users so please be patient.

Queues App in Action

Once settings and policies have synchronized the Queues App will be visible (if pinned) on the side bar. Take note of the Auto Attendants and Call Queues across the top and the historical reports available in the upper right corner through Analytics.

Important - Understanding the Queues App and Auto Attendant / Call Queue Settings

While the Queues App provides an enhanced interface for calling, follow-up, agent presence, and call statistics - control over greeting messages, agent selection, and call routing is accessed through the Teams Client settings (for authorized users)

Navigate to Settings -> Calls for administrative controls over each attendant and queue

Note - the small purple icon will identify an Auto Attendant or Call Queue.

As the Queues App is in public preview - get started now, and remain patient as feature enhancements roll out through the GA stages.

This guide provides a solid foundation for getting started with the Queues App in Teams. While there are numerous comprehensive contact center integrations available for organizations requiring full-featured experiences or CRM integration, the Queues App combined with Teams Premium offers a valuable solution that bridges the gap between basic queue needs and a fully-featured contact center.

Stay tuned - in the next chapter we will cover specific personas and real-world use of the Queues App.

Teams Admin Units for device management

As organizations grow, managing roles and devices efficiently becomes critical. Microsoft Entra ID’s administrative units allow for precise role assignment and scope, ensuring admins access only the necessary resources. The recent enhancement in Microsoft Teams enables device management within administrative units, allowing admins to control devices in specific regions or departments. For instance, an IT admin can now manage devices only in their assigned locations, without viewing or affecting others globally. This powerful combination strengthens security with principle of  least privilege (PoLP) and simplifies device management with improved organizational efficiency. This is the first addition with ongoing development of administrative units in Teams Administration.

In the first quarter of 2024, Microsoft launched a new administrative role to assist managing Telecom features in Teams. 

Earlier this month, the next step in administrative support followed with the announcement of administrative units for device admins.

Reference Links:

Use Microsoft Teams administrator roles to manage Teams - Microsoft Teams | Microsoft Learn

Assign or list Microsoft Entra roles with administrative unit scope - Microsoft Entra ID | Microsoft Learn

Manage devices with administrative units - Microsoft Teams | Microsoft Learn

Microsoft Teams: Administrative Units for Teams Administration

We are excited to announce the availability of administrative units (AUs) for Teams administration. AUs are a way to delegate admin roles and delegate administration to a subset of users in your organization, based on attributes such as department, location, or business unit. With AUs, you can create more granular and flexible management scenarios for your Teams environment. You can assign the following roles, allowing them to manage only the users, groups & devices within their AU: Teams Administrator Teams Device Administrator Teams Communication Administrator Teams Communication Support Engineer Teams Communication Support Specialist Teams Telephony Administrator

• Feature ID: 402186
• Added to roadmap: 6/26/2024
• Last modified: 8/6/2024
• Product(s): Microsoft Teams
• Cloud instance(s): Worldwide (Standard Multi-Tenant)
• Platform(s): Desktop, iOS, Android, Mac
• Release phase(s): General Availability

Lets take a closer look:

Global admins can create administrative units to segregate Teams Device management across the enterprise. Following the documentation links above, starting in EntraID, to create an admin unit.

With no user devices assigned to the scope of the Admin Unit - while Lee (our device admin) can access the Teams Admin Center, and view the device menus, yet no devices are visible. This is where I needed to do some investigation ... do we add the user account who access the device or just the EntraID device itself. The documentation wasn't explicitly clear here so I hope this post helps.

Manage users or devices for an administrative unit with rules for dynamic membership groups (Preview) - Microsoft Entra ID | Microsoft Learn

Once I added the devices user account to membership - the scoped admin unit rules took place and we are able to see the devices just for that admin unit - as shown below for Lee.

and an MTR just to be thorough.

For reference - Adele is a Device Admin with non-scoped permanent role assignment and able to see the entire estate of devices.

Hope this post helps get you started with Admin Units for Teams device administration.

Call Records Insights Update 2 - Export UPN from Entra ID and update Call Records

In the previous chapter of CRI, I discussed an option for inserting user UPNs into the 'Call Record Insights' query results. To further simplify the work of administrators, this post will explore how to automate the integration of user and UPN data from Entra ID. We'll cover how to automate the replacement of this table on a scheduled basis using Azure Automation (Runbooks) or PowerShell.

Recap

The previous posts on Teams Call Record Insights covered getting started and query updates to include additional data. Below are links to those chapters.

• Introduction to CRI - Getting Started
• Update CRI with user UPN
• Rotate and update user UPN table (this post)

In the last session we reviewed how to create and populate user UPN's in the CRI database, and then use Kusto Query join to return the UPN in the call records query.

The real takeaway from the last chapter—and this post—isn't just about adding UPNs to call records; it's about empowering your organization with complete ownership, management, and flexibility of your records database. Once implemented, this data is yours to control, allowing you to retain, modify, and adapt it as your needs evolve.

Previously, we created the user_UPN table through the ADX web interface, setting up a new table and importing users, GUIDs, and UPNs using the data import tool in ADX.

But what if you need to ensure this user UPN table stays up-to-date daily, reflecting changes as users are added or removed from your tenant

Automation of table data

Given my familiarity with PowerShell and runbooks, and the added support from GitHub Copilot, this demonstration will focus on automating the process using PowerShell and Azure Automation (Runbooks). While this could also be achieved with C# or Python (I initially experimented with Python but ultimately chose PowerShell for the final solution), PowerShell’s robust capabilities made it the ideal choice for this task.

The Process

First, we'll connect to Entra ID and export the upn, display name, and GUID into a CSV file. Then, we'll rename the existing user_UPN table to keep a backup without including it in future queries. After that, we'll create a new, blank user_UPN table and import the CSV data from Entra ID to populate it with updated user information. From the previos session, I chose to export and populate upn, GUID, and display name but only upn and one of the other fields are required to match and join from the CRI table. Additionally, I've incorporated some error checking and output presentation for validation, which is helpful during setup but not necessary for the final runbook

Step 1 - connect and export user data

# Define the CSV path with a date stamp

$dateStamp = Get-Date -Format "yyyyMMdd"

$csvPath = "[your directory path]\userExport_$dateStamp.csv"

# Ensure you're connected to Azure

Connect-AzAccount -Tenant "[your tenant ID]"

# Fetch user information

$users = Get-AzADUser | Select-Object DisplayName, Id, UserPrincipalName

# Export to CSV

$userCount = $users.Count

Write-Host -ForegroundColor Blue "Number of users: $userCount"

$users | Export-Csv -Path $csvPath -NoTypeInformation

# Display in a table if needed

$users | Format-Table -AutoSize

# Prompt the user to proceed to update the Kusto database

$proceed = Read-Host "CSV file generated at $csvPath. Do you want to proceed with updates to CRI Kusto Database (yes/no)"

if ($proceed -ne "yes") {

    Write-Host "Operation aborted by the user."

    exit

}

Note - with runbook the Write-Host and Prompt to proceed should be omitted.

Step 2 - Import modules, libraries and set variables (Kusto libraries can be downloaded and locally referenced)

Reference THIS LINK for details on Kusto in PowerShell.

# Define the tenant ID, client ID, and client secret of the service principal

$tenantId = "[your tenant ID]"

$clientId = "[your client ID"

$clientSecret = "[your client secret]"

$authority = "[your tenant domain name]" 

# Define the path to the Kusto client libraries

$kustoLibPath = "[your library path]\net6.0\"

# Load the Kusto client libraries in the correct order

Add-Type -Path "$kustoLibPath\Microsoft.Identity.Client.dll"

Add-Type -Path "$kustoLibPath\Kusto.Data.dll"

Note - ClientID, ClientSecret and Authority are needed when not using a user login, or when running script as runbook where service principle is required. This section of the documentation explains the variables needed with User, Application or Azure CLI interaction with Kusto in PowerShell.

Step 3 - Create Kusto query with Kusto Custom String Builder and Client Request Properties

# Define Kusto connection string variables

$clusterUrl = "[your Azure Data Explorer cluster url]"

$databaseName = "CallRecordInsights"

# Create the Kusto connection string with the OAuth token if using service principal

$kcsb = [Kusto.Data.KustoConnectionStringBuilder]::new($clusterUrl, $databaseName)

$kcsb = $kcsb.WithAadApplicationKeyAuthentication($clientId, $clientSecret, $authority)

# Define client request properties

$crp = [Kusto.Data.Common.ClientRequestProperties]::new()

$crp.ClientRequestId = "UserUPNpsh.ExecuteQuery." + [Guid]::NewGuid().ToString()

$crp.SetOption([Kusto.Data.Common.ClientRequestProperties]::OptionServerTimeout, [TimeSpan]::FromSeconds(30))

Step 4a (run as user) or 4b (run as application)

Here is an example of a query to test connecting and querying the manually created  user_UPN table and displaying the output to screen. (this would not be needed or valuable in a runbook)

# Query and present the existing table to test

$queryProvider = [Kusto.Data.Net.Client.KustoClientFactory]::CreateCslQueryProvider($kcsb)

$query = "user_upn | take 10"

Write-Host "Executing query: '$query' to test access to Kusto with connection string: '$($kcsb.ToString())'"

$reader = $queryProvider.ExecuteQuery($query, $crp)

$dataTable = [Kusto.Cloud.Platform.Data.ExtendedDataReader]::ToDataSet($reader).Tables[0]

$dataView = New-Object System.Data.DataView($dataTable)

$dataView | Sort DisplayName | Format-Table -AutoSize 

Here is the steps to rename the existing table and create a new table, ingesting the previously created CSV file, and ignoring the top header row (we don't want to ingest the column headers as data in the Cosmos DB table). Also note: Write-Host and Proceed lines should be omitted in a runbook.

# Rename the existing user_upn table to user_upn_old to preserve the table

$renameQuery = ".rename table user_upn to user_upn_old"

Write-Host -ForegroundColor Blue "Executing rename query: '$renameQuery'"

# Execute the rename query

try {

    $queryProvider.ExecuteControlCommand($renameQuery, $crp)

    Write-Host "Table renamed successfully."

} catch {

    Write-Host "Error renaming table: $_"

}

# Prompt the user to proceed to update the Kusto database

$proceed = Read-Host "User_upn renamed. Do you want to proceed with updates to CRI Kusto Database (yes/no)"

if ($proceed -ne "yes") {

    Write-Host "Operation aborted by the user."

    exit

}

# Define the create table query to recreate user_upn table with new upn data

$createTableQuery = @"

.create table user_upn (

    DisplayName: string,

    Id: guid,

    UserPrincipalName: string

)

"@

Write-Host -ForegroundColor Blue "Executing create new table: '$createTableQuery'"

# Execute the create table query

try {

    $queryProvider.ExecuteControlCommand($createTableQuery, $crp)

    Write-Host "New table created successfully."

} catch {

    Write-Host "Error creating new table: $_"

}

# Ingest data into the new table

$rowCount = (Import-Csv -Path $csvPath | Measure-Object).Count

Write-Host -ForegroundColor Blue "Executing table data ingest with $rowCount records:"

# Construct the ingestion query to ingest the CSV file into the table, and remove the column headers from the table data

$csvContent = Get-Content -Path $csvPath -Raw

$csvLines = $csvContent -split "`n"

$csvLinesWithoutHeader = $csvLines | Select-Object -Skip 1

$csvContentWithoutHeader = $csvLinesWithoutHeader -join "`n"

$tableName = "user_upn"

$ingestQuery = @"

.ingest inline into table $tableName <|

$csvContentWithoutHeader

"@

# Execute the ingestion query

try {

    $queryProvider.ExecuteControlCommand($ingestQuery, $crp)

    Write-Host "CSV file ingested successfully into the table $tableName."

} catch {

    Write-Error "Failed to ingest CSV file: $_"

}

Write-host -ForegroundColor Green "User UPN data updated successfully. Please check Kusto database for the updated data."

Azure Automation

Create Automation Account

Assign Roles and Perms for Automation Account

1. Enable Managed Identity for the Azure Automation Account:

   • Navigate to your Azure Automation account in the Azure portal.
   • Under "Account Settings", select "Identity".
   • Enable the System-Assigned Managed Identity or add a User-Assigned Managed Identity.

2. Assign Azure Roles:

   • Go to the "Access control (IAM)" section of your subscription.
   • Add a role assignment for the managed identity with the Contributor role at the subscription level. This ensures it has the necessary permissions to manage resources within the subscription.
   • Additionally, assign the Reader role on the Azure AD to the managed identity. This allows it to read user information.

3. Grant Azure AD Permissions:

   • Navigate to the Azure AD section in the Azure portal.
   • Go to "App registrations" and find the managed identity.
   • Under "API permissions", add the Directory.Read.All permission.
   • Grant admin consent for the permission.

or run script to assign permissions

# Install the Microsoft Graph PowerShell module if not already installed
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Application.ReadWrite.All", "AppRoleAssignment.ReadWrite.All", "Directory.Read.All"

# Find the managed identity
$DisplayNameOfMSI = "<Your-Managed-Identity-Name>"
$MSI = Get-MgServicePrincipal -Filter "displayName eq '$DisplayNameOfMSI'"

# Find the Microsoft Graph service principal
$GraphAppId = "00000003-0000-0000-c000-000000000000"
$GraphServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$GraphAppId'"

# Find the app role for Directory.Read.All
$PermissionName = "Directory.Read.All"
$AppRole = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}

# Assign the app role to the managed identity
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MSI.Id -PrincipalId $MSI.Id -ResourceId $GraphServicePrincipal.Id -AppRoleId $AppRole.Id

Lets build the automation account

Runbooks can be environment specific, we can load the Kusto Client DLLs from storage already created during the CRI deployment steps - from the NUGET file share in the CRI storage account. Optionally you could create blob storage and upload the libraries from this link - https://www.nuget.org/packages/Microsoft.Azure.Kusto.Data/

# Define the path to the Kusto client libraries

$kustoLibPath = "[your library path]\net6.0\"

# Load the Kusto client libraries in the correct order

Add-Type -Path "$kustoLibPath\Microsoft.Identity.Client.dll"

Add-Type -Path "$kustoLibPath\Kusto.Data.dll"

These libraries are required for the script to construct the Kusto client query, used in this context:

$kcsb = [Kusto.Data.KustoConnectionStringBuilder]::new($clusterUrl, $databaseName)

I also simplified the runbook, removing the dependency to write and store the user data in CSV, and just held the data in temp storage (JSON format) in the script.

# Fetch user information

$users = Get-AzADUser | Select-Object DisplayName, Id, UserPrincipalName

# Convert user data to JSON format for Cosmos DB ingestion

$usersJson = $users | ForEach-Object {

    [PSCustomObject]@{

        DisplayName       = $_.DisplayName

        Id                = $_.Id

        UserPrincipalName = $_.UserPrincipalName

    }

}

In our query we get UPN's in our call records, with an automated process to keep things up to date:

Next

I hope this post helps share the flexibility and specific ways to integrate additional data into call records with automation. You may not need this specific use case, but experiment with data integration needs for your organization.

In our next chapter we will investigate visualizing Call Record Insights in Power BI, and the value of CRI data retention in comparison to Teams Call Quality Dashboard, and QER in PowerBI - and way to leverage CRI to investigate call issues and correlate call ID's between TAC and CRI.

Thanks

JB

Call Record Insights Update - Add User Principal Name to Records

In my previous post, "Getting Started with Call Record Insights," I discussed the basics of working with Call Record Insights (CRI). Since then, I've been focusing on an important update: including the user UPN (User Principal Name) in each record. Currently, CRI provides the user display name and user ID (GUID) but doesn't support UPN yet. The CRI development team has assured me that UPN support is coming in a future release. However, I have a few clients who need a quick and easy solution now. In this post, I'll walk you through a few modifications that will enable you to surface the UPN for each record right away.

The Challenge:

A record query in Call Record Insights (CRI) only provides the UserDisplayName, Id (GUID), and roles such as Callee, Caller, and Organizer. However, many organizations require a common identifier for consistent reporting and analytics. The UserPrincipalName (UPN) is highly desired in call records to standardize identity references and streamline reporting outputs.

The Process:

First we need to gather the UPN data and create a table for CRI to map.

Start with a simple PowerShell to get users DisplayName, GUID and UserPrincipalName

# Ensure you're connected to Azure

Connect-AzAccount -Tenant "YourTenantID"

# Fetch user information

$users = Get-AzADUser | Select-Object DisplayName, Id, UserPrincipalName

# Export to CSV

$users | Export-Csv -Path "YourFileLocation\userExport.csv" -NoTypeInformation

# Display in a table if needed

$users | Format-Table -AutoSize

This is a one-time step to get started. Later we will cover methods to keep the table up-to-date as new users are added to the tenant. In this example, I chose to export Display Name, ID (GUID) and UserPrincipalName - only 2 of these 3 fields are required, the goal later in our KQL steps, is to create a join, matching either ID (GUID) or UserDisplayName between the new table, and CRI to return the UPN.

Next add this table to Cosmos DB using Azure Data Explorer. There are options to do this through PowerShell using the Az.CosmosDB module, in this guide will leverage Azure Data Explorer (ADX).

Navigate to ADX and connect to the Cosmos DB. You can find the direct link (URI) to the CRI instance in the Azure portal. Select the resource group, and the Azure Data Explorer instance, and the copy the URI. Paste into new browser window, authenticate with the needed credentials, and select "Trust".

The next step is to add our CSV export data, including UserPrincipalName, as a new table in the existing CallRecords database. Select Get Data, as noted above, and then select Local File as the data source.

Expand the CallRecords database, and select New Table. Update the new table name to user_upn and in the right hand pane, drag/drop or browse for the CSV export generated from the PowerShell script. Click Next.

ADX shows a preview of the table creation from the CSV file. Note, toggle "First row is column header" to prevent the headers from inserting as rows in the table.

Click Finish - watch the table creating and record updates. When competed you will now find the new table.

The magic happens in our KQL query were we create a table join to match user ID's to UPN and return the UPN in our output.

In this example we need to return UPN for caller and callee records. This query can also be updated to create a third join on organizer if needed.

In the Query window - the following KQL will select the desired fields, join the tables using Caller_UserId and Callee_UserId to the Id(GUID) field in user_upn and return the UPN for both callers and callees.

(Please modify the query below if table names, or column names differ in your deployment)

CallRecords
| sort by CallStartTime desc
| extend CallDuration = todatetime(CallEndTime) - todatetime(CallStartTime)
| project CallId, SessionId, StreamDirection, MediaLabel, CallStartTime, CallEndTime, CallDuration, Caller_UserDisplayName, Caller_UserId, Caller_PhoneId, Callee_UserDisplayName, Callee_PhoneId, Callee_UserId, Caller_UserAgentHeaderValue, Callee_UserAgentHeaderValue
| join kind=leftouter (user_upn | project Id, UserPrincipalName) on $left.Callee_UserId == $right.Id
| extend Callee_UPN = UserPrincipalName
| project-away Id, UserPrincipalName
| join kind=leftouter (user_upn | project Id, UserPrincipalName) on $left.Caller_UserId == $right.Id
| extend Caller_UPN = UserPrincipalName
| project-away Id, UserPrincipalName
| project CallId, SessionId, StreamDirection, MediaLabel, CallStartTime, CallEndTime, CallDuration, Caller_UserDisplayName, Caller_UPN, Caller_PhoneId, Callee_UserDisplayName, Callee_UPN, Callee_PhoneId,Caller_UserAgentHeaderValue, Callee_UserAgentHeaderValue

• From the previous post, we used extend to calculate and create the call duration in the query results
• The first join operation matches Callee_Id from CallRecords with ID from user_upn and projects the UserPrincipalName into a new field called Callee_UPN.
• The second join operation matches Caller_Id from CallRecords with ID from user_upn and projects the UserPrincipalName into a new field called Caller_UPN.
• The project-away operator is used after each join to remove the unnecessary ID and UserPrincipalName fields from the intermediate results.
• The final project operator lists all the fields you want to include in the final output, including the new Callee_UPN and Caller_UPN fields.

The Outcome:

Comparing the basic Take 100 query noted above in the Challenge section, to the new output, the UPN fields are now present in the output.

In the next chapter, we will create an automation job to upkeep the user_upn table as new members are added to the tenant. Stay tuned.

Unleashing Creativity and Collaboration with Microsoft Whiteboard and Copilot

Whether you're brainstorming ideas, planning a project, or conducting a team meeting, having the right tools can make all the difference. Enter Microsoft Whiteboard and Copilot, a dynamic duo that enhances productivity and fosters innovation. In this blog post, we'll explore how these tools work together to create a seamless collaborative experience.

What is Microsoft Whiteboard?

Microsoft Whiteboard is a digital canvas that allows users to brainstorm, ideate, and collaborate in real-time. It's designed to be intuitive and easy to use, providing a range of tools that mimic traditional whiteboarding but with the added benefits of digital technology. You can draw, write, and add sticky notes, images, and diagrams to your whiteboard, making it a versatile tool for any collaborative task. For enhanced collaboration, integrate the whiteboard into Team chat or meetings, allowing participants to actively contribute, share ideas, and engage in real-time brainstorming sessions.

Introducing Copilot: Your AI Assistant

Copilot is an AI-powered assistant integrated within Microsoft's suite of productivity tools. It helps streamline tasks, offers suggestions, and automates routine processes, allowing you to focus on the creative and strategic aspects of your work. With Copilot, you can enhance your productivity and make the most of your collaborative sessions on Microsoft Whiteboard.

Welcome to Copilot in Whiteboard - Microsoft Support

Design Thinking - Retrospective Use Case

Recently our team was using a Design Thinking process, while Whiteboard has many retrospective templates, we chose the Rose, Bud and Thorn option, leveraging  a  framework which helps identify positives, opportunities, and challenges.

Consider multiple contributors collaboratively adding note cards over time, filling the whiteboard with numerous virtual 'sticky notes,' some of which overlap in concept. Now, it's time to categorize and summarize this information.

In steps Copilot in Whiteboard.

With a quick selection, we can remove duplicates, request additional ideas, categorize the topics, and summarize.

Similar to an 'Easy Button,' Copilot seamlessly integrates input and ideas from multiple collaborators, organizing and summarizing them directly within the Whiteboard app. This allows everyone to review the content in real-time, eliminating the need for separate discussion breaks for later review.

Conclusion

Combining Microsoft Whiteboard with Copilot creates a powerful environment for creativity and collaboration. By leveraging the strengths of both tools, you can enhance your productivity, streamline your workflows, and foster innovation within your team. Whether you're brainstorming new ideas, planning a project, or conducting a meeting, Microsoft Whiteboard and Copilot are here to help you succeed.

Get started with the template options in Whiteboard, and leverage Copilot to save time and simplify.

Thanks Don Donais, Mark DeRosia, Mike Rinner, and Scott Francis for navigating this exercise together.