Linking Meeting Room Tablet to Google Workspace: Two Ways to Connect
If you have connected a room booking product to Microsoft 365 before, the Google Workspace version will surprise you, and it is better to be surprised now than on the afternoon you had set aside for it.
Google grants calendar access to the person who signs in. There is no way to authorise an application on its own, the way Microsoft 365 allows. That single fact shapes everything about connecting Google Workspace to a room display system, including why there are two routes rather than three, and why nobody can email the approval to an administrator and go for lunch.
Below, we discuss what that constraint means in practice, the two ways to connect, and how they compare on setup, ongoing effort and security.
The One Fact That Explains All of This
On Microsoft 365, an administrator can approve an application and walk away. The application then holds its own permission and runs with nobody signed in. That is why the Microsoft side of this product has a one-click Quick Connect option.
Google does not work that way. Whoever completes the sign-in becomes the identity the displays run as, permanently. There is no application identity to grant anything to.
Two consequences follow, and both are worth knowing before you book the meeting.
There is no Google Quick Connect. One was offered once and has been withdrawn. A one-click route could only ever hold one person's authorisation, which means the panels would run as that individual, reach only the rooms that person can edit, and stop working the day their account was disabled or their password reset. That is not a shortcut. It is a fault waiting for a leaving date.
The approval cannot be handed off. On Microsoft, if you are not an administrator, the product emails the approval request to whoever you name and you finish the job when they have granted it. On Google there is no equivalent, because approving and signing in are the same act. Whoever completes it becomes the credential. Somebody has to be at the keyboard with the account's password.
Plan for that. It is the difference between a thirty minute session with your Workspace administrator and three weeks of calendar tennis.
The Route
Route 1: Service Account
This is the standard path and the one we recommend.
Your Workspace administrator creates one ordinary user account for the displays to use, something like rooms@yourcompany.com. They share each meeting room's calendar with it, and then somebody signs in as that account, once.
The account belongs to nobody. It reaches exactly the rooms you shared with it, nothing else in your Workspace and no personal calendars. It outlives everybody, which is the entire point. When the person who set it up leaves, nothing happens.
The advantage is that it is the simplest route and also the narrowest. The account does not need to be an administrator. An administrator is needed once, to create it and share the rooms, and then not again. Google returns a long-lived authorisation which is stored encrypted and refreshed automatically, so there is nothing for you to renew, no certificate, no expiry date in your calendar.
The downside is a small amount of account hygiene and one missing convenience.
The hygiene: the account needs a non-expiring password, it needs excluding from any policy that would make it re-verify, and it needs to be exempt from two-step verification. It also needs excluding from your leaver process, and documenting, because a year from now somebody will find an unused account with a non-expiring password and no MFA and be entirely right to ask about it. Name it for its job and write down what it is for.
The missing convenience: on this path the room list comes from the calendars shared with the account, which gives you each room's name but not its capacity, building or floor. You type those in once when you add the room, and they behave identically afterwards. The Google directory scope that carries those details is deliberately not requested here, because Google will grant an administrator scope to a non-administrator account quite happily and then refuse every call that uses it. Asking for it would advertise a room list this account cannot actually read.
Who it suits. Almost everyone.
Route 2: Advanced Setup
Bring your own credential. Your team creates a service account in a Google Cloud project your organisation controls, enables domain-wide delegation on it, authorises two specific scopes in the Admin console, and hands the platform a JSON key plus an administrator identity to impersonate.
The advantage is ownership, and one genuine functional gain. The credential belongs to your organisation, in your project, which is what some policies require and there is no arguing with a policy. And because this route does read the Google directory, capacity, building and floor arrive filled in rather than typed. On a large estate that is real time saved.
The downside is that this is the most involved path in the product, and it has a signature failure mode worth naming out loud.
Enabling domain-wide delegation in the Cloud console and authorising the scopes in the Admin console are two separate settings in two separate places, and only the second one grants anything. A service account with delegation enabled but no Admin console entry authenticates perfectly and returns nothing at all. No error at sign-in, no error at save, just an empty room list and empty agendas. It is the defining way Google setups go wrong, and it is hard to diagnose precisely because everything reports success.
There are two smaller traps in the same area. The Admin console wants the service account's numeric client ID, not its email address, and the two are easy to confuse. And delegation changes take a few minutes to propagate, so a failure immediately after authorising the scopes is often just impatience.
The other ongoing cost is the impersonated administrator. A delegated service account acts as a user, so it needs somebody to act as. If that person leaves and their account is suspended, syncing stops for the whole connection. Impersonate a role account rather than a person.
Who it suits. Organisations whose policy requires the credential to be one they created, and large estates that want the directory details populated automatically.
How They Compare
The Microsoft article in this series ends on a trade-off: the narrowest option is also the most work. Google does not work like that, and it makes the choice easier.
Ease of setup. Service account, clearly. One account, room sharing, one sign-in. Advanced setup spans two Google consoles and fails silently if you miss a step.
Ongoing effort. Closer than it looks, and it splits. The service account needs its password, its two-step exemption and a share on each new room you add. Advanced needs no per-room step, because it reads the directory, but it carries key custody and a dependency on the impersonated administrator staying active. Neither is heavy. Both are the sort of thing that breaks eighteen months later when somebody tidies up.
Security. The service account reaches exactly the rooms shared with it, and nothing else. Domain-wide delegation is broad by its nature, since it impersonates an administrator. So if the question is how much can this reach, the service account wins.
Which produces an unusually clean recommendation. On Google, the simpler route is also the narrower one. Unless your policy specifically requires a credential you created, the standard path is better on both counts and there is nothing to trade away.
Comparison
Service account | Advanced setup | |
|---|---|---|
Setup time | About 30 minutes with an administrator | Longest path in the product, two consoles |
Who owns the credential | You do, it is an account in your Workspace | You do, it is a key in your Cloud project |
How access is scoped | Exactly the rooms you share with the account | Domain-wide delegation, impersonating an administrator |
Room capacity, building, floor | Typed in once per room | Read from your directory automatically |
Per-room work | Share each room's calendar | None |
Renewal | None, refreshed automatically | None, but the key is yours to look after |
Breaks later because | Two-step verification, a password policy, or the account was suspended | Scopes never authorised, or the impersonated admin left |
Recommended for | Almost everyone | Policy-bound organisations and large estates |
Four Things That Catch People
1. Read access is not enough. Each room must be shared with permission to make changes to events, not just to see event details. A room shared read-only will not be listed at all, which is deliberate, because otherwise it would look bookable and then fail the first time somebody pressed Book at the panel.
2. Two-step verification breaks it later, not now. The initial sign-in succeeds because a person is standing there to answer the prompt. The unattended refresh weeks later has nobody. This is the single most common cause of a Google setup that works on the day and fails a month afterwards.
3. Signing in as yourself is one click away. Your own account is sitting on Google's account chooser, already signed in. The product checks which account signed in and refuses the connection if it is not the one you named, so the cost is a repeated attempt rather than a connection that quietly depends on you. It is still the mistake this whole design exists to prevent.
4. Rooms must be calendar resources. A shared calendar named after a room is not a bookable resource and will not appear. If people already book these rooms through Google Calendar's resource picker, this is already true.
One more, if your Workspace restricts third-party application access. An administrator has to allow the application under the Admin console's API controls, or the sign-in is refused outright.
Which to Choose
Use the service account route. It avoids domain-wide delegation, which is where most Google setups go wrong, it is narrower in what it can reach, and there is nothing to renew.
Use Advanced setup only if your policy requires the credential to belong to your organisation rather than to an account in your Workspace, or if you are fitting enough rooms that having capacity, building and floor arrive automatically is worth the extra work.
Whichever you pick, do the Google side completely before you open the connection dialog, and do it in one sitting with your administrator. Coming back to it later is what stalls these setups, and on Google there is no way to email the remaining step to somebody else.
Wrapping Up
The Google path is not harder than the Microsoft one. It is differently shaped, and the difference is entirely explained by Google granting access to a person rather than to an application.
Take a technology company of around 400 people running entirely on Google Workspace. Their setup went perfectly. The administrator created the account, shared eighteen rooms with it, signed in, and every panel was live inside an hour. Three weeks later all eighteen went stale on the same morning. The account was inside the organisation's two-step verification policy, which nobody had thought about because the initial sign-in had a human present to approve it. The unattended token refresh did not. Exempting one account fixed it in five minutes, and the lesson cost them a fortnight of people not trusting the panels, which is much harder to get back than the connection was.
Do the account hygiene at the same time as the setup, not afterwards. Non-expiring password, exempt from two-step verification, out of the leaver process, written down.
If you are on Google Workspace and want a second pair of eyes on the setup before you book time with your administrator, tell us how your rooms are configured and we will tell you what to prepare.
---
Frequently Asked Questions
How many ways are there to connect Google Workspace?
Two. A service account you create in your Workspace, which is the standard route, and Advanced setup using a service account in your own Google Cloud project with domain-wide delegation.
Why is there no one-click option for Google, when Microsoft has one?
Because Google grants calendar access to whoever signs in. A one-click route could only hold one person's authorisation, so the displays would run as that individual and stop when their account did. It was offered once and withdrawn.
Can I send the approval to our administrator by email?
No. On Google, approving and signing in are the same act, so whoever completes it becomes the credential. Somebody has to be at the keyboard with the service account's password. The Microsoft routes do support an email hand-off.
Does the service account need to be a Workspace administrator?
No. An administrator is needed once, to create the account and share the room calendars with it. The account itself is an ordinary user.
What can it actually reach?
Exactly the room calendars shared with it. Nothing else in your Workspace, and no personal calendars.
Why are capacity and building empty on our rooms?
On the service account route the room list comes from the shared calendars, which carry names but not directory details. Type them in once when you add the room. Advanced setup reads them from the directory instead.
Do we have to renew anything?
No. Google returns a long-lived authorisation that is stored encrypted and refreshed automatically.
What happens if we suspend the service account?
Every display stops updating. That is the trade for it not depending on any individual, so treat it as infrastructure and keep it out of your leaver process.
