Microsoft Bookings has been around for a VERY long time in Microsoft 365, and a few years while a Microsoft person was screen sharing, I noticed he had a personalised Bookings experience inside of Outlook on the web.

Unfortunately, my enquiries about when those outside of Microsoft would see this fell on deaf ears, until earlier this year when I was shown a very early preview of “Bookings with Me”.

I’ve been using it for a number of months now and have recently introduced my colleagues to it – especially those who had previously set up a Microsoft Bookings “business” calendar as a way to offer ease for external people wanting their time.

Other than sending it via email or chat in ad-hoc conversations, ideally we’d want it to be automatically added to your signature. And while Bookings with Me does offer you the ability to get the URL to insert in your signature, it doesn’t work in places where you have automatic signature solutions.

For almost a decade, I’ve been using Exclaimer with Exchange Online to populate email signatures, and generally use Intune to disable policies that allow staff to customise their email signatures in Outlook – which is more for convenience and consistency than any kind of overbearing administration.

While people may complain initially that they don’t see their signatures when composing an email, that goes away within days as the benefits outweigh the slight convenience.

The Challenge

Our email signatures pull data from our Microsoft 365 / Azure Active Directory profiles to populate the fields, so at first I tried to examine where via Microsoft Graph I could retrieve this Bookings with Me URL that was used – but unfortunately it is not accessible from there.

Long story short, thanks to some friendly folks at Microsoft who shared a script that had been built for a different purpose of Bookings with Me, I discovered that a user’s public page URL is actually made up of their Exchange GUID as well as SMTP domain.

As this is also not available through Microsoft Graph, the only option is PowerShell.

Fundamentally I have no issue with PowerShell, but I wanted a system users could enable or disable this URL in their email signature without having to go to IT.

The Solution

There’s probably a bunch of different ways to approach this, so don’t shoot me if you know of a better way or can improve my solution – suggestions are welcome.

What I opted for, was a solution that would take the Exchange GUID, clean up the format, and add the necessary text before and after to construct the entire URL.

The Exchange GUID looks like this: 7314bbc1-5324-400e-8c10-2af3d2e89b4a.

The full URL we want looks like this: https://outlook.office.com/bookwithme/user/7314bbc15324400e8c102af3d2e89b4a@domain.com.com?anonymous&ep=plink.

Effectively, the address used is the user’s Exchange GUID but without the hyphens in between.

In order to get the URL stored in a location that Exclaimer could access, I chose to utilise an extension attribute as each user has 15 of those available.

The solution works as follows:

The Components

• App front end for users to toggle on/off
• Workflow to retrieve the current status of Bookings with Me in their signature
• Workflow to set their Bookings with Me public page URL in their signature
  • Child workflow to call the Azure Automation Runbook
• Azure Automation Runbook
• Workflow to remove their Bookings with Me public page URL from their signature

All of the Power Platform components are packaged up in a single solution:

App front end for users to toggle on/off

A relatively simplistic app in appearance. Could it be prettier? Sure.

The app is connected to the following workflows:

The primary configurations of the app will run the workflow (which only takes 1 second) to retrieve the current value of extensionAttribute1:

App OnStart

ClearCollect(CurrentStatusBookWithMeEnabled,’USERS-GetcurrentstatusofBookwithMeinemailsignature’.Run(User().Email))

The toggle will show the current state of the attribute based on the workflow run in the OnStart. If you check it, it runs the workflow to set the attribute. If you uncheck it, then it clears the attribute. Simple yeah?

Toggle

Default: If((First(CurrentStatusBookWithMeEnabled).bookwithmeenabled=”True”),true,false)

OnCheck: ‘USERS-SetBookwithMeURLinextensionAttribute1’.Run(User().Email)

OnUncheck: ‘USERS-BookwithMe-clearextensionAttribute1’.Run(User().Email)

Workflow to retrieve the current status of Bookings with Me in their signature

This is the workflow from the app OnStart that takes the UPN and does a quick check in Graph to see if extensionAttribute1 is populated or not:

Expanded view:

The Condition is set to Run After the previous step because if extensionAttribute1 is null then the condition action may not run – but we want it to run anyway so it can set the variable to False.

Workflow to set their Bookings with Me public page URL in their signature

If the toggle shows as Disabled, and the user flicks it to Enabled, then this workflow will run.

In this workflow, I have broken out the Azure Automation into a child workflow so that I don’t have to grant users of the app access to the resource group that the Azure Automation account sits in. It also means I don’t have to share the workflow and configure it to use a Run As account.

I have also chosen to use HTTP to call the child workflow, as I found using the actual calling of a child workflow still passes across the permission requirements – so this works around it.

(We get the URL of the child workflow in a later step.)

The compose looks like this:

concat(‘https://outlook.office.com/bookwithme/user/’,body(‘Parse_JSON_-_child_workflow_results’)?[‘ExchangeGUID’],’@YOUREMAILDOMAIN.COM’,’?anonymous&ep=plink’)

Child workflow to call the Azure Automation Runbook

Here is where we call the Runbook in Azure Automation and pass the parameter down from the previous workflow, as well as the results back up to it.

The compose looks like this:

replace(outputs(‘Get_job_output’)?[‘body’],decodeUriComponent(‘%0D%0A’),”)

Azure Automation Runbook

Here is the part of the brains behind the solution. Without this, the rest of it is pointless.

Ideally you will already have an Azure Automation Runbook for Exchange set up for other purposes, but if not Tony Redmond has a good post explaining how to set it up.

Here is the script we are calling from Power Automate that gets the Exchange GUID and removes the hyphens:

Workflow to remove their Bookings with Me public page URL from their signature

If for some reason people don’t want their Bookings with Me public page URL in their signature, then they can flick the toggle in the app back to Disabled and it will run this workflow.

Adding the URL to your signatures

If you’re using Exclaimer or a similar solution that supports extension attributes, we can use the presence of the attribute to determine which signature is applied.

In the signature where I’ve applied the URL I can use the Advanced Query to select them:

I’m keeping the rule here to only look for the presence of the domain. I could use outlook.office.com or a fuller URL if I wanted to be more specific.

To exclude them from getting the existing signature without the Booking with Me URL, simply add the same query to the exceptions:

And running it through the Signature Rule Tester in Exclaimer, here’s our result:

Conclusion

You don’t need to be using a third-party email solution for this to work, even using Exchange Online transport rules could allow this to occur.

You could also argue that using cloud-based email signatures in Outlook should avoid this – however I would argue that people shouldn’t set their own signatures, because I don’t care to see my email conversations filled up with signatures from every response. Plus, plenty of other reasons.

In any case, the solution file and script are available on my GitHub repository.

---

Also published on Medium.