Meeting rooms and room panels

What a room panel reads, and what it never writes

A panel outside a meeting room should read the room's own calendar rather than an employee's. The calendar belongs to the space: it survives people joining and leaving, it is the object the customer's IT already curates, and nobody objects to it being on a wall in a corridor.

It is also far less work to set up across an estate. One administrator consent covers every room in the organisation, where signing in each employee would be an OAuth round trip per person.

For each booking Mirra reads the subject, the start and end, the location and the first part of the body. It does not ask for attendee lists.

• There is no write path. No booking from the panel, no check-in, no releasing a no-show — not disabled, not built.
• There is no room browser. Listing an organisation's rooms needs a directory permission that cannot be narrowed, so you paste each address instead. It is validated by actually reading the calendar, which is a stronger check than a listing would have been.
• Google Workspace resource calendars are not supported. Same idea, entirely different authentication; it would be its own connection type.
• Personal Microsoft accounts cannot do this. There are no resource mailboxes in one, and no administrator to consent.

Step 1 — connect Microsoft 365

This is a conversation with an IT department rather than a household setting, so it has its own page. A Global Administrator has to complete it.

1. Go to Integrations → Calendar → Set up meeting rooms

   Or open /integrations/calendar/rooms directly.

2. Check the page is not telling you it is unconfigured

   "Microsoft 365 isn't configured on this install" means MS_CLIENT_ID and MS_CLIENT_SECRET have not been set. That is a job for whoever runs the install, and nothing on this page will work until it is done.

3. Have a Global Administrator press Connect Microsoft 365

   They are taken to Microsoft's standard administrator consent prompt, on behalf of the whole organisation.

4. Read what it asks for — it will name no calendar permission

   That is deliberate and it is the point of the whole design. Consenting here grants Mirra no access to anything; it registers the application in your tenant so that Exchange has something to assign a role to in step 2.

5. You return to the rooms page

   It now shows "Microsoft 365 connected", your organisation's identifier, and who consented.

Mirra does not trust the organisation identifier that Microsoft puts in the return address — anybody could put anything there. It immediately asks Microsoft for a token for that organisation, which only succeeds if the organisation has genuinely consented. That request is the proof; the return address is a suggestion of what to try.

Step 2 — grant access in Exchange, scoped to your rooms

This step is the only one that grants Mirra any access at all, and it is where the access is narrowed to the rooms you nominate.

The reason it is done in Exchange rather than in Entra is worth stating, because a security reviewer will ask. An application permission granted in Entra is tenant-wide: Calendars.Read there would be every mailbox in the organisation, permanently, and no amount of Exchange configuration would narrow it — Microsoft is explicit that the two systems are a union. The only way to hold genuinely scoped access is to hold no Entra grant at all.

1. Put the room mailboxes into a mail-enabled security group

   This group is what the scope is defined against, so adding a room later is a group membership change rather than another PowerShell session.

2. Copy the four commands from the rooms page

   They are printed in full on the page, with placeholders. You will need to substitute the application id and object id of the Mirra enterprise application from your Entra tenant, and your group's distinguished name — the page does not fill these in for you.

3. Run them in Exchange Online PowerShell

   They register the application with Exchange, create a management scope matching only that group, assign the "Application Calendars.Read" role against that scope, and then test it.

4. Use the fourth command to prove the scope

   Test-ServicePrincipalAuthorization should succeed for a room in the group and fail for a mailbox outside it.

5. Wait

   Exchange caches application permissions for somewhere between thirty minutes and two hours. The test command can report success while Microsoft Graph still refuses. This is normal and is not a fault at either end.

If you have done something like this before with New-ApplicationAccessPolicy, note that Microsoft now documents that as legacy and says new configuration should not use it. The commands on the page use RBAC for Applications, which is the current mechanism.

If somebody later grants Calendars.Read in Entra to be helpful, the scope silently disappears and nothing breaks — Mirra can then read every mailbox in the organisation and no error appears anywhere. Nothing breaking is exactly why Mirra tries to read a mailbox it should be refused, and shows a red banner when it succeeds. Use that check, and remove the Entra grant if it fires.

Step 3 — add the rooms

Each room is added by pasting its mailbox address. Mirra reads the calendar before creating anything, so a room is never added and then discovered to be unreadable after forty panels are on the wall.

1. Paste the room mailbox address

   For example boardroom@example.com.

2. Give it a name for the panel, if you want one

   Left blank, the name is the part of the address before the @.

3. Press Add room

   Mirra makes one narrow read against that mailbox — a single day, not four months, because this is a permission check rather than a calendar fetch.

4. Read the answer if it refuses

   "Exchange has not granted this app access to that mailbox yet" means the role assignment has not taken effect — wait, and use Check again. "No mailbox with that address in this organisation" means a typo. Anything else is ours.

5. Check the row that appears

   Live means Mirra holds a change subscription for that mailbox; Polling means it does not, and the room is read on the next five-minute refresh. Neither is a fault. Note that a room's change notification is only ever pushed to screens assigned to that room, and nothing in the portal assigns one — so today a room's changes reach a panel on the five-minute poll either way. See the caution under Pointing a panel at a room.

Room mailbox address

The room's own SMTP address. Validated by reading its calendar, so it cannot be saved unless it works.Default: Empty — required

Name on the panel (optional)

What the calendar is called on the wall and in the room list.Default: The part of the address before the @

Check the scope (optional)

A mailbox Mirra should not be able to read — an ordinary employee's address does nicely. Being refused is the answer you want.Default: Empty

Removing a room stops the reads and cancels the change subscription, but leaves the organisation's consent alone. The consent is still real — revoking it is an administrator's act in Entra — and forgetting it here would mean a second full consent round trip to add one room back.

Proving the grant is actually scoped

A scoped grant and an unscoped one are indistinguishable from inside the rooms they both cover. The only proof available is to try to read a mailbox that should be refused, and hope to be refused.

1. Type a mailbox Mirra should not reach into "Check the scope"

   An ordinary employee's address is the obvious choice.

2. Press Check again

   This also re-probes every room you have added, which is what you want during the first two hours after the Exchange role was assigned.

3. Read the banner

   "Scope confirmed: a mailbox outside the group was refused" is the good outcome. The red banner — "This app can read a mailbox it should not be able to" — means somebody has granted Calendars.Read in Entra as well, and it should be removed.

Where no control address is given, Mirra records the answer as unknown rather than as confirmed. A missing or misspelt control mailbox proves nothing either way, and a green tick taken from a typo would be a false assurance in the one place that must not carry one.

Pointing a panel at a room

Each of the four calendar widgets has a Calendar setting that chooses what it reads.

This screen's room

Resolved on the server through the screen's own record, so one scene could be deployed to forty door panels and each show its own room. See the caution below before choosing it.Default: Not the default

All calendars

Everything the household has connected, merged and sorted — plus that screen's own invited meetings, if it has an address.Default: The default

A named calendar

One connected calendar by name, including a meeting room. A panel asking for a specific calendar is checked against the household that owns it, because the layout a screen is holding is data rather than authority.Default: Not the default

"This screen's room" is set on the screen itself: open the screen from the dashboard and use **This screen's room** in the right-hand column. That is what lets ONE scene go on every door — a panel set to this shows whatever is booked in the room it is mounted outside, so forty doors share one scene instead of needing forty. Choosing the room by name in the Calendar widget still works and is the right answer when a screen shows a room it is not outside — a lobby board listing the boardroom, say.

An empty agenda is not a free room

Everywhere else in Mirra, a calendar that failed to load and a calendar with nothing in it look the same and it hardly matters — a kitchen wall showing no events on a quiet Tuesday is telling the truth either way.

On a door it is the opposite. An empty agenda outside a meeting room is a claim that the room is available, and somebody acts on it by walking in. So the four calendar widgets have a third state, and they use it: "Calendar unavailable", with "This is not a claim that nothing is booked" underneath.

If you see it on a panel, the room could not be read. It is not a statement about the room's diary.

Inviting a screen to a meeting

There is a second way to get a meeting onto a wall, and it needs no consent, no administrator and no vendor at all: give the screen an email address, and add it to the meeting the way you would add a colleague. It works from any calendar client on any platform, including the ones Mirra will never have a connector for.

It is a public inbox on the internet, so it is off by default for every screen, the address carries a checksum that makes guessing pointless, and it can be thrown away and replaced at any time.

• The invited meetings appear only on the screen that was invited, and only when its widget is reading all calendars.
• One inbox accepts a hundred messages a day and keeps two hundred meetings, dropping the oldest meeting first — an inbox at its limit should lose last year's, not this afternoon's.
• Cancellations are honoured properly, including the awkward case of a series cancelled after somebody has moved one instance of it. A cancelled meeting left on a wall is the worst thing this feature can do.
• Forgery is possible and is tolerated. Anyone can put anything in a From header, and a forged invitation puts a meeting on a wall — it reads nothing and reaches nothing. Replacing the address undoes it.
• Removing the screen from a meeting's attendee list sends no cancellation. The organiser's client stops including the address and nothing tells Mirra, so a meeting removed that way stays on the wall until it passes. There is no fix for this within the protocol.
• Mirra never replies to an invitation, so the organiser sees the address as an attendee who has not responded. Attachments and prose are ignored — only the calendar part of the message is read.

This needs the mail side of the install to be set up, and today it has no page in the portal. The pipeline is built and the endpoints exist, but nothing in the interface creates a screen's address, shows it, or throws it away, so it cannot be turned on by a household without help from whoever runs the install.

Things that look like faults and are not

• Every meeting titled with a person's name. A room mailbox ships configured to delete the subject and substitute the organiser, which is correct and discreet rather than broken. Changing it is an Exchange setting, and it is opting into less privacy rather than fixing a bug.
• "Exchange has not granted this app access to that mailbox yet" for an hour or two. That is the permission cache, not a mistake. Press Check again.
• A genuinely booked room showing nothing. Most often an external organiser and an Exchange setting that has the room ignore meeting messages from outside. An Exchange setting, not a Mirra one.
• A room that stopped working after being renamed. Mirra keys on the mailbox address on purpose, because Microsoft documents the room's internal id as not immutable — a renamed mailbox fails visibly instead of silently resolving somewhere else.
• A room removed and re-added within a week that says Polling. The previous change subscription has not expired yet, so a new one cannot be created for that mailbox. It sorts itself out inside seven days, and nothing on the wall is affected in the meantime.
• Every room failing at once. That is the organisation's consent rather than forty rooms. The rows and configuration survive it, so re-consenting restores an estate rather than rebuilding it.