# How to Send Microsoft Bookings Appointment Alerts to a Shared Room

> Use the Microsoft Bookings trigger, fixed privacy-minimal copy, and a stable appointment key to notify one shared PingRoom Room.

- Published: 2026-11-08
- Author: PingRoom
- Category: Developers
- Topics: Microsoft Bookings notifications, Microsoft Bookings Power Automate, Microsoft Bookings appointment alert, webhook push notifications
- Canonical: https://pingroom.io/blog/microsoft-bookings-appointment-push-notifications
- Cover image: https://pingroom.io/blog/microsoft-bookings-appointment-push-notifications-cover.webp
- Cover description: Two PingRoom avatars keep appointment cards behind a wooden divider while Pingo watches one blank signal token reach a shared tray.

To send a Microsoft Bookings appointment alert to a shared group of phones, start a Power Automate flow with **When a appointment is Created**, use `SelfServiceAppointmentId` as the event key, and post fixed copy to a PingRoom incoming webhook. Keep the customer, service, staff, time, location, notes, and meeting link in Microsoft Bookings.

This is a Power Automate webhook recipe, not a native Microsoft Bookings integration. Microsoft Bookings remains the appointment record. PingRoom carries one small update to the people in a private Room.

## Use Microsoft staff notifications first

Microsoft Bookings can already [notify assigned staff](https://learn.microsoft.com/en-us/microsoft-365/bookings/notify-staff-member-assigned-booking?view=o365-worldwide) when bookings are created or changed. Start there when the assigned staff are the people who need to know.

Add a shared Room only when a stable group needs the same low-context signal:

| Need                                                            | Better starting point                             |
| --------------------------------------------------------------- | ------------------------------------------------- |
| Assigned staff need normal booking details and calendar changes | Microsoft Bookings and Outlook notifications      |
| A customer needs a confirmation or reminder                     | Microsoft Bookings email or eligible SMS settings |
| A team works in Microsoft Teams                                 | A Teams action in the existing flow               |
| A small opt-in group needs only “an appointment was created”    | Fixed copy to a private PingRoom Room             |
| The booking starts regulated, urgent, or safety-critical work   | The approved case system and escalation path      |

The Room should not become a second appointment database. Anyone who needs the customer name, service, time, location, notes, staff assignment, or joining link should open Microsoft Bookings through the access their organization already controls.

## Check the connector boundaries

This setup needs:

- a Microsoft 365 account with an eligible Microsoft Bookings license;
- the **Administrator** role for the selected Bookings business;
- the Bookings business SMTP address;
- a Power Automate environment where the HTTP action is allowed by licensing and tenant data policy; and
- active PingRoom Pro on the destination Room owner's account.

Microsoft's [Bookings connector guide](https://learn.microsoft.com/en-us/microsoft-365/bookings/power-automate-integration?view=o365-worldwide) says only Bookings admins can create appointment-trigger flows. It also limits each Bookings mailbox to five appointment-trigger flows. If an existing flow already starts from the same trigger, consider adding this action there instead of spending another mailbox slot.

The connector listens to one Bookings business. Copy its SMTP address from the Bookings **Integrations → Power Automate** area. Do not substitute a person's email address or a personal Bookings page.

## Create the private destination

In PingRoom, create or choose a private Room for the people who need this signal. Open **Settings → Connections → From another app**, add an incoming webhook named **Microsoft Bookings**, keep **Quick Ping** on **Custom message**, save it, and copy the complete URL.

The URL is a credential: anyone who has it can trigger that Room webhook. Keep it out of booking fields, browser code, screenshots, shared templates, and ordinary logs. The [incoming-webhook setup guide](/blog/webhook-to-push-notification) covers the Room side; the [webhook reference](/documents/webhooks) lists the current fields, errors, replay behavior, and limits.

## Build the smallest useful flow

Create an **Automated cloud flow** in Power Automate and select the Microsoft Bookings trigger named **When a appointment is Created**. The wording is Microsoft's current connector label. Select or paste the SMTP address for exactly one Bookings business.

Add a **Condition** before the webhook action. Continue only when this expression is true:

```text
not(empty(triggerBody()?['SelfServiceAppointmentId']))
```

If the identifier is missing, terminate the flow as failed. Do not fall back to the connector's older `Id` field. Microsoft's [connector reference](https://learn.microsoft.com/en-in/connectors/microsoftbookings/) marks `Id` as deprecated and documents `SelfServiceAppointmentId` as the identifier shared by create, update, and cancel events.

In the valid branch, add a **Compose** action named `Event_key`:

```text
concat('msbookings-', string(triggerBody()?['SelfServiceAppointmentId']))
```

Then add an **HTTP** action:

| HTTP field               | Value                              |
| ------------------------ | ---------------------------------- |
| Method                   | `POST`                             |
| URI                      | the protected PingRoom webhook URL |
| Header `Accept`          | `application/json`                 |
| Header `Content-Type`    | `application/json`                 |
| Header `Idempotency-Key` | output of the `Event_key` Compose  |

Use a fixed body:

```json
{
  "title": "New Microsoft Bookings appointment",
  "message": "A new appointment was created in Microsoft Bookings."
}
```

Do not insert dynamic customer or appointment fields into that body. In the HTTP action's **Settings**, enable **Secure Inputs** and **Secure Outputs**. Microsoft's [sensitive-input guidance](https://learn.microsoft.com/en-us/power-automate/how-tos-use-sensitive-input) explains those controls. They reduce accidental exposure in run history; they do not replace restricted flow access, tenant policy, or secret rotation.

The result is deliberately plain:

> **New Microsoft Bookings appointment**
>
> A new appointment was created in Microsoft Bookings.

The team opens Microsoft Bookings for the actual record. The Ping does not say who booked, what they booked, when it starts, which staff member is assigned, or whether someone reviewed it.

![Two PingRoom avatars test a miniature retry gate while Pingo watches one blank appointment token pass and an identical retry stop.](/blog/microsoft-bookings-appointment-push-notifications-1.webp)

[Pingo the Pigeon](/Pingo), PingRoom's fictional Chief Marketing Officer, appears beside the miniature gate. His contribution is a patient look at the duplicate token. He cannot open Microsoft Bookings, enter the private Room, edit the flow, or send the Ping. People configure and own the workflow.

## Know what the create trigger leaves out

The create trigger represents the appointment entity being created. For a group booking, Microsoft's connector reference says the first customer creates that entity. Adding later customers produces **update** events, not more create events.

This recipe therefore sends one appointment-created signal, not one signal per attendee. Do not add the update trigger merely to count later attendees: updates also cover other appointment changes, and the connector does not identify exactly what changed. Keep attendee state in Microsoft Bookings.

Create, update, and cancel events can all carry the same `SelfServiceAppointmentId`. That makes it useful for event identity, but a complete lifecycle workflow would also need the event kind in its key and copy. This article intentionally handles only creation.

## Rehearse six boundaries

Use a disposable Bookings business or harmless test service, a private test Room, and no real customer data.

1. **First appointment:** create one test appointment. Confirm one fixed Ping appears in Room history.
2. **Exact retry:** resubmit the same flow run without changing the HTTP body. The same appointment ID and body should return the accepted result without creating another Ping.
3. **Changed body:** in the test flow, change the fixed message and resubmit the captured appointment. PingRoom should return `409 idempotency_conflict` because one key cannot describe two bodies.
4. **Second appointment:** create another test appointment. Its different `SelfServiceAppointmentId` should produce one new Ping.
5. **Group booking:** add another attendee to the same group appointment. The create-only flow should not claim that a new appointment was created.
6. **Unavailable destination:** disable the test webhook and confirm the HTTP action follows the flow's failure path instead of reporting success.

For this article, we ran the fixed mapping against Microsoft Bookings-shaped fixtures and a stateful local mock of PingRoom's documented incoming-webhook contract. The check covered first acceptance, exact replay, changed-body conflict, a second appointment, missing and malformed identifiers, disabled-webhook behavior, and exclusion of customer, service, staff, time, location, notes, and meeting-link fields. It did not use a live Microsoft tenant, Bookings business, Power Automate flow, PingRoom Room, appointment, customer record, phone, or notification delivery.

## Read acceptance narrowly

HTTP `200` with `success: true` means PingRoom accepted the request or returned the completed result for the same event key. It does not prove every phone displayed an alert. Network conditions, operating-system permissions, Focus modes, Room preferences, and device settings still apply.

Microsoft Bookings remains authoritative for the appointment. Power Automate remains authoritative for the flow run. PingRoom is the attention path, not the schedule, customer record, audit log, or escalation system.

Review the [general Power Automate phone-alert recipe](/blog/power-automate-push-notifications) before adding dynamic copy to another workflow. For this Bookings flow, fixed copy is the safer boundary. When the six checks pass, [create or choose the destination Room](/app/rooms) and keep the appointment details where they belong.

_The two editorial illustrations were created with AI using approved PingRoom character references and reviewed by the PingRoom team._