Google booking account for protected resources

Organization administrator guide — granting one booking identity write access to resource calendars that stay free/busy for everyone else

• Applies to: Google Workspace Calendar resources connected through the Google Workspace integration
• Audience: Google Workspace and Calendar administrators
• Version: 19 August 2026

About this manual

Many organizations share resource calendars with everyone at the free/busy level: colleagues can see that a room is occupied, but not who booked it or why. That default is deliberate, and it should usually stay.

TRMNL Booking still needs to create and cancel events on those calendars. This manual explains how to prepare one Google account that holds write access to specific resource calendars while the organization-wide sharing default remains unchanged, and how to confirm that TRMNL sees the resulting access.

Scope: Calendar access only. Creating buildings, features, and Calendar resources, connecting the integration, and validating displays are covered by the Google Workspace administrator guide.

Roadmap

1. Understand how TRMNL decides that a calendar is bookable.
2. Prepare a dedicated booking account.
3. Confirm the organization-wide sharing default and leave it alone.
4. Grant the booking account Make changes to events on each resource calendar.
5. Prove the access in Google Calendar.
6. Connect or refresh the resource in TRMNL and confirm it is no longer read-only.

1. How TRMNL decides that a calendar is bookable

The OAuth consent screen is not the deciding factor. TRMNL always requests calendar event access, but Google reports a separate access level for every individual calendar, and that per-calendar level is what TRMNL uses.

Google also returns writerWithoutPrivateAccess where an account may change events but not see the details of private ones. TRMNL treats that as bookable. See section 10 before choosing between it and writer.

A read-only resource behaves consistently everywhere in Booking:

• The calendar carries a Read only badge under Calendars.
• Its page shows a Read-only calendar notice instead of a booking QR code.
• Its public booking link is withdrawn, and a collection QR skips it.
• A booking attempt is refused before Google is contacted.

Two consequences are worth remembering:

• An administrator role is not calendar access. The privileges that let an account list buildings and Calendar resources say nothing about whether it may write to a resource's calendar. A Super Admin who has never been granted access to a resource calendar can still be freeBusyReader on it.
• TRMNL learns the access level when it reads a calendar. The level is refreshed every time the resource's schedule is fetched, so a permission change in Google appears in Booking only after the next synchronization or refresh. If Google later refuses a read outright, the resource is marked read-only until a successful refresh restores it.

Google reference: Calendar access roles

2. Prepare the booking account

Use one dedicated, long-lived account rather than an individual's identity. Its properties, license requirements, and rotation procedure are described in Recommended account model.

Example:

trmnl-booking@example.com

For this manual the account must:

• Belong to the Workspace domain being connected.
• Have Google Calendar enabled.
• Hold the administrator privileges required to list buildings and Calendar resources.
• Be granted calendar access explicitly, by the procedure in section 4.

Granting the account write access to a resource calendar does not change what anyone else can see. The grant applies to that one account on that one calendar.

3. Prerequisites

☐ The booking account exists, is licensed, and has Calendar enabled.

☐ The Calendar resources to be displayed already exist in Google Admin.

☐ An administrator can change the sharing settings of those resource calendars.

☐ The organization's current sharing default is known and documented.

☐ The administrator has access to the TRMNL account that owns the Booking installation.

4. Grant write access to a resource calendar

Resource calendar permissions are managed in Google Calendar, not in the resource record itself. Perform this as an account that may manage the resource, such as a Super Admin.

1. Sign in to Google Calendar.
2. Next to Other calendars, select Add other calendars, then Browse resources.
3. Subscribe to the resource whose calendar TRMNL will book.
4. Hover the resource in the calendar list, open its options, and select Settings and sharing.
5. Under Share with specific people or groups, select Add people and groups.
6. Enter the booking account address, for example trmnl-booking@example.com.
7. Set its permission to Make changes to events.
8. Select Send.
9. Repeat for every resource TRMNL should be able to book.

Choose Make changes and manage sharing only if the booking account is also expected to administer the calendar's permissions. Booking does not require it.

Google reference: Calendar access permissions

4.1 Granting many resources at once

Adding the account to each resource individually does not scale past a handful of rooms. Share each resource calendar with a group instead:

1. Create a group such as trmnl-booking-writers@example.com.
2. Add the booking account as its only member.
3. Grant that group Make changes to events on each resource calendar, using the procedure above.

Membership then controls access. Rotating to a replacement booking account becomes a membership change rather than a sweep through every resource. Group permission changes can take longer to take effect than direct grants, so allow for propagation before concluding that a grant failed.

5. Leave the organization-wide default alone

The organization-wide levels live in the Google Admin console under Apps > Google Workspace > Calendar > Sharing settings. They decide what everyone in the domain sees by default, including the free/busy-only option this manual assumes.

The grant in section 4 is an exception for one account on named calendars. It does not require, and should not be accompanied by, a change to those organization-wide options. Relaxing the default to make TRMNL work would expose event details across the whole domain to solve a problem that a per-calendar grant already solves.

Google reference: Set Google Calendar sharing options

6. Prove the access in Google first

Confirm the grant with the booking account itself before involving TRMNL. This separates a Google permission problem from a TRMNL synchronization problem.

1. Sign in to Google Calendar as the booking account.
2. Open the resource calendar. Subscribe to it through Browse resources if it is not already visible.
3. Confirm its existing events are visible rather than anonymous busy blocks.
4. Create a short pilot event on the resource calendar.
5. Delete the pilot event.

If step 4 fails, the grant did not apply to this account or this calendar. Do not continue until it succeeds.

7. Apply the access in TRMNL

If the Workspace integration is not yet connected, connect it as the booking account by following Connect Google Workspace to TRMNL.

If it is already connected as the booking account:

1. Open Apps > Booking > Integrations and select Synchronize on the Google Workspace account.
2. Confirm the resource is selected under Synchronized Calendars.
3. Open the resource under Calendars and refresh it.
4. Confirm the Read only badge and the Read-only calendar notice are gone.

An access level granted in Google reaches TRMNL only through a calendar refresh, so a resource can remain marked read-only for a short time after a correct grant. Refresh the resource before investigating further.

If the connected account is being replaced rather than granted access, follow Account rotation and offboarding.

8. Verification

☐ The organization-wide sharing default is unchanged.

☐ The booking account can create and delete an event directly on the resource calendar in Google.

☐ The resource shows no Read only badge under Calendars.

☐ A TRMNL booking appears on the Google resource calendar.

☐ A conflicting booking is rejected.

☐ Cancelling in TRMNL removes or cancels the Google event.

☐ The Booking with TRMNL QR code is available where Booking with TRMNL is enabled.

9. Troubleshooting

10. Write access and event privacy are separate

Write access and detail visibility are two different decisions, and it is worth making them deliberately:

• Make changes to events (writer) lets the booking account create bookings and see the details of every event on that calendar, including private ones. Those details can then appear on a physical display or a public booking page.
• Make changes to events without private details (writerWithoutPrivateAccess), where Google offers it, keeps booking working while private event details stay hidden. TRMNL accepts it as bookable and shows a generic busy interval for those events.

Choose the narrower level where displays are in public areas. Do not widen a calendar's sharing to make titles appear on a screen — decide first whether those titles belong on a screen at all.

Related reading: Security and privacy and Booking with TRMNL.

11. Ongoing review

Review at the same interval as the rest of the integration:

• The booking account is active and its Calendar service remains enabled.
• Its calendar grants still exist on every displayed resource.
• Group membership matches the intended booking account.
• Resources added in Google Admin since the last review have been granted access and selected under Synchronized Calendars.

Google documentation

• Calendar access permissions
• Set Google Calendar sharing options
• Administrator privilege definitions
• What is a Calendar resource?
• Calendar access roles
• Calendar access control rules