Teams apps – Help me use the Teams bot with a compliance policy

We are nearly complete on an AI solution – it is being built on top of Microsoft Teams and Azure OpenAI APIs. We call it SSW YakShaver.

The product has a blocking issue. We are recording a Teams call (and screen) and we have hit something called a “compliance policy”.

The below is what we plan to do from here. I would have assumed we would have gone with Option 1 (using the Teams bot with a compliance policy) but it seems like we are going to use the Graph API (simpler).



I got this email from the YakShaver team:

We have been trying to get the compliance policy working in MS Teams (Option1), but have pretty much given up.

We have decided to do Option 2 below followed by Option 2.1.

We are *not* doing Option 1.

Here are all the points we have learnt.

Then the user flow.

Then the pros and cons.

Option 1: Media Stream – Application hosted or compliance recording bot (Not recommended)

Using a Teams bot with a compliance policy to record the audio and video, it will record every participants sound individually, those who are not in the policy will not be recorded.

  • Complexity – on the backend
  • We need the compliance policy on everyone in the call for them to be recorded
  • User adds bot to the call or meeting, it will directly start to record, when the user kick out the bot it will stop.
  • The bot will send an api call to the endpoint /api/call
  • After this we need to connect with Microsoft Media Stream
    • From the Media Stream we can get the video stream.
  • We need to add in a way to store the videos so that Media Stream to do this
    • Suggestion: Use data blob (YakShaver Teams bot store video in datablob, and media stream pulls it)
      • We could send it directly to the api, but according to Uly we need to store the video somewhere so the final PBI can have a link to it.
      • When we’re using the compliancy policy it’s not recording as normally and the video will not be stored in Stream as it would normally would be

User flow

  1. User adds bot to the call or meeting.
  2. It will directly start to record, and the user can tell the task.
  3. When the user kicks out the bot, it will stop the recording and send of the task.

✅ Pros:

  1. No frontend needed, just an instruction page
  2. Easy on the user end, the user never needs to start recording and stop recording, instead the user can just add and remove the bot.

❌ Cons:

  1. Complexity of coding on the backend
  2. Saving Audio and video files is a problem
  3. Audio might be recorded separately among participants, and if so, it requires coding to re-join them together
  4. We need extra work to notify the user that they are being recorded
  5. Potential legal issue because we record it and we are responsible for it, we need some extra safety rules on the recorded audios
  6. We need to run the whole thing on the windows VM.

Info – Application Hosted Bot

Option 2: Use the Graph API (Recommended)

Using the Graph API to do the work, the user manually start and stop recording, and then the YakShaver will get the transcrips for the user manually.

  • Delegated auth flow, everyone can be recorded.
  • Access to transcript need a PAT (personal access token)
  • We can’t access the start and stop recording from the API so this has to be done manually.
  • User start recording, user end recording
  • Since the user is starting and stopping the recording – the recording is stored on their account and everyone in the meeting has access to it
    • That’s why we need their PAT to access the recording/transscript
    • Later: investigate how we can move the recording to another location where everyone have access

User flow (⚠️worse flow, but quicker to develop and cheaper $ Azure costs)

  1. User start recording
  2. User click on YakShaver tab button before or after recording
  3. User stop recording
  4. The YakShaver will do the task

✅ Pros:

  1. Less software complexity
  2. No need to save video stream and no need to merge transcripts.
  3. We have the UI so the YakShaver can track the issue being created and show it on the UI
  4. It’s already been proved to work in POC
  5. We can sell it to a client because it’s all using delegated permissions

❌ Cons:

  1. We need some front-end work, pop ups, SSOs to manage user credentials.
  2. More steps on the user end, manual recording is annoying and not natural.

User Flow – Options to skip the extra clicks (7 clicks in total):

Option 2 requires us to manually start and stop the recording in Teams. The following are 2 options to get around that.

Option 2.1: Azure Communication Service

Use communication service to automate the call record process – need a POC after Graph is done.

✅ Pros:

– It’s easy to use

– We can get rid of the compliance policy which is much much simpler!!!!!

– I can see the potential of making YakShaver into a commercial project.

– We can define our own compliance rule rather than rely on Azure to set up the compliance policy

❌ Cons:

– Calls have to be initialized from communication services

– It’s our responsibility to notify recording – very important

– We have to do compliance recording policy ourselves if we make it commercial later – might need a lawyer

How Azure Communication Services endpoints work with the Graph API?

Things we are sure of from the documentation:

  1. Azure Communication services can initialize a call, if the call is from Azure communication services, we can record it anytime
  2. Azure Communication services might be able record teams call but it might not.
  3. The call might not be on Teams.

When the users are calling the other user from YakShaver

  1. Can call another user from YakShaver and click record on YakShaver
  2. Users being invited to another call
  3. Inside that call, everything will be recorded

When 2 users are on a call and all of a sudden they decide to use YakShaver

  1. YakShaver will call them
  2. All users will be muted on teams
  3. All users will be invited to another call
  4. The newly created group call will be recorded

What happens if it’s a scheduled meeting

  1. We don’t need Azure communication service, the delegated flow should just be working….

Option 2.2: Click script

  • Could use this if Option 2.1 fails
  • What user interaction with computer can’t be done with an old-school click script?

Help me customize Azure Access Review emails

SysAdmins find it a lot of work to keep giving people permissions to resources like Azure.

I wanted to say that we’re now really enjoying using Azure Access Reviews. We’ve written about how we use it on

At SSW we have so many Teams and Groups – almost all set to public. Since people can join so many, they poke around, join a group, and never leave. That means they are included in every calendar appointment and every team email and the noise was reported as an employee dissatisfaction.

Access Review has been invaluable because it effortlessly removes users when they no longer need access. We have set it to run every 3 months and they need to say they are still a member.

❌ The Access Review email does not look like anything SSW SysAdmins would send, so it gets deleted mistakenly by many people in our company.

Having the ability to customize the email is important.


  • Email subject – Give the ability to edit
  • Email body – Give the ability to edit text
  • Email body – Give the ability to add an image
  • Email body – Having placeholders for significant fields, like Group, would be ideal (see ‘SSW SugarLearning’ in the image)
  • From address – Currently employees think it is ⚠️spam from Microsoft, not from SSW SysAdmins. So it would be a big bonus if we could send the notifications from our own email address to prevent any confusion.
Figure: ❌ Bad example – Email shows limited context and looks just like a lot of other notifications that we get

Azure DevOps – Show Display Name from Azure AD

We have Azure DevOps connected to Azure AD so that our users can log in with their Azure AD credentials.
Currently, DevOps does not show our users’ Display Name that is set in Azure AD.

Users can change their own name here, but this is not a fix. For the sake of consistency, display names should match the display names used in Azure AD.

Figure: Display Name in Azure AD (with [SSW])
Figure: Display Name in Azure Devops (missing [SSW])

Help me know instantly what Tracing Mode is via a rename

Today I showed at NDC Oslo how to build a bot manually with C# and Blazor using the Azure OpenAI GPT services.

Then I showed how to do the same thing automatically with the new PVAs.

At the end I did a poll of the audience (about 300 people) – the Norwegians vote was about 80% saying they preferred the PVA solution.

Well done – the 1st impression is awesome ⭐

Keep the $ attainable please… it is the danger point for adoption.

Little UX suggestion… Regarding this “Tracing Mode” screen.
I reckon I would rename it to “Query Execution Plan” or maybe just “Execution Plan”

Then you keep the same name as you have in SQL Server: