Setting staff calendar sharing internally, at scale
I’m a big fan of the scheduling assistant in Outlook. It’s the equivalent of patiently waiting for someone to finish talking before you start. However many people don’t know this feature exists, and while many do know about it — they don’t have enough visibility to make it that useful.
The Challenge
Unfortunately, with some people’s calendars only showing their Free/Busy, it can be difficult to make an informed decision as to whether what you are trying to schedule is potentially more important than what they have in their schedule already.
For many people, setting their calendar permissions for internal colleagues is not something they either remember to do, and in some cases, even know is possible. What you end up with is this:
By showing what’s available in your calendar, it’s not so much about letting others override based on their perceived level of importance — but it at least makes it easier to have a conversation or make a request if something needs to change.
Possible Solution
In Outlook, users can share their calendars with individuals, but there is also a “My Organization” which is a blanket target that… you guessed it: applies to everyone in the organisation.
While users can follow the instructions on this Microsoft Support article to share their calendars, it’s just one of many individual tasks that they need to remember to do.
One way I’ve seen work previously, is having a PowerShell script run on a regular basis that applies the permission change using the Exchange Online PowerShell module. This could probably work nicely in an Azure Automation runbook, but to me it’s too many dependencies.
Actual Solution
I opted to create a solution in Power Automate which effectively does two things:
- Get a listing of users to apply the change to (more on that later)
- Run a Graph command against each of them to apply the permission
Here’s what the Flow looks like:
Let’s break this down in more detail.
Firstly, we want this workflow to run every day because not all staff start on a Monday:
Secondly, let’s set the variables for the app we registered in Azure AD:
Then let’s extract the listing of people we want to apply this to. You can use either a security group or M365 Group, ultimately it comes down to who you want target.
While for me it would make sense to apply to everyone in our country Team, unfortunately that has some people (including senior leadership) from outside of our little island continent. If that doesn’t apply to you, you can use an org-wide Team’s underlying M365 Group, or if it does then a security group makes sense as it can be more targeted.
And now for the final step, making the Graph API call to update the specific permission:
The chosen permission is “Limited Read”, which as outlined in the Graph calendarRoleType values equates to “User is a sharee who can view free/busy status, and titles and locations of the events on the calendar”.
Effectively this allows us to see basic information about the appointments in our peers’ calendars, but not the full details, and certainly not any private events.
And to make this work, we just need an app registration in Azure AD with a pinch of permissions:
You may be wondering why my workflow applies this to all group members, and not just any new ones? That’s a fair question.
The primary reason is convenience and consistency. I could have a step where it queries each user to see what their level of calendar permission is and then only target those who don’t have the correct level set, but that’s extra effort and doesn’t really add any benefit. Instead, we just apply the same level each day to the targeted group of users and can get on with scheduling.
This can be used at any level — team, department, country, organisation — it’s completely up to you (and what level of access you have to create Azure AD app registrations with the necessary permissions).
Hopefully this leads to better meeting requests; although that requires the humans to do their part and actually utilise this functionality and visibility!
Originally published at Loryan Strant, Microsoft 365 MVP.
