Let people sign in with Google Workspace
Put a Google button on the sign-in page so people use their work account instead of an Offision password. Two minutes, once the integration is connected.
When single sign-on is on, the Offision sign-in page carries a Google button, and people use the work account they are already signed into. No second password, and nothing to reset when they change the first one.
What to have ready
- The Google Workspace integration connected, in a mode that signs people in
- A decision on what the button should say
- For your own OAuth app: the sign-in redirect URI already added to the OAuth client
1. Find the setting
It is not called single sign-on on the integration card. Open the Google Workspace tile, and on the integration card choose the Login button name row — that is the sign-in settings.
Open IntegrationsWhen sign-in is off, that row shows a red User login is disabled instead of a button name. That is the fastest way to check whether this is on, and the first thing to look at when someone reports the Google button missing.
2. Turn on user login
Switch User login on.
Sign-in settings: the user login switch and the button name people read.
3. Name the button
Login button name is the text on the sign-in page. It is the one string in this whole integration that ordinary staff will read, so write it for them rather than for the IT team — Sign in with Google or the name of your organisation, not GWS SSO Provider.
Left empty, the button falls back to Offision’s own wording. If you connect more than one Google Workspace organisation, this is also the only thing that tells people which button is theirs. Name them distinctly.
4. Check it worked
Sign out, or open a private window, and load the Offision sign-in page. The button should be there with the name you gave it. Sign in with a Google Workspace account and confirm you land in Offision with the right permissions.
Test with an ordinary account, not an administrator — an administrator has permissions of their own, and will not reveal a missing default user group.
Where the sign-in credentials come from
Worth knowing when sign-in behaves differently from the calendar side.
- On quick connect, sign-in runs through a shared Offision registration. There is nothing to configure and nothing to expire.
- On your own OAuth app, sign-in uses your OAuth client. This is also why its redirect URI matters: without it Google has nowhere to send people back to, and the failure looks like a rejected password.
When it goes wrong
| What you see | Usual cause |
|---|---|
| No Google button on the sign-in page | User login is off, or this connection is in Resource calendar mode |
| The Login button name row shows user login disabled | Exactly that — turn user login on |
| No sign-in row on the card at all | Resource calendar mode, which carries no sign-in permission |
| Sign-in returns to the login page with no error | The sign-in redirect URI is missing from your own OAuth client |
| Google says the redirect URI does not match | The URI in the OAuth client differs from the one Offision shows — often by a trailing slash |
| Sign-in works but the account cannot do anything | No default user group, so the account arrived with no permissions |
| Sign-in works for some people, not others | They are not in Offision yet. Google does not sync people — add them first |
| Two Google buttons and nobody knows which | Two connected organisations with the same button name |