What Google connection unlocks

Google offers two integrations on the platform: Google Calendar and Google Drive. They are independent: a member can connect a calendar without the workspace having a Drive connected, and the workspace can connect a Drive even if no calendars are wired up. Connecting Google Calendar lets the platform read freebusy intervals (so your booking page never offers a slot when you have a conflict on your personal or work calendar) and write events (so confirmed bookings, Q&A sessions, and Let's Coordinate meetings appear on your calendar with the right attendees and a Google Meet link if applicable). Connecting Google Drive lets the platform provision a case-folder tree for every Transfer Room, route signed agreements and deliverables and received client files into the right folder automatically, and back up Secure PDF Tools output through Save to Drive across the workspace.

Calendar is per-member, Drive is per-workspace

Google Calendar connections are per-member. Every teammate connects their own calendar from My Profile, and bookings the teammate handles land on the teammate's personal calendar. This is the only sensible model when multiple teammates take bookings independently: nobody wants their personal calendar polluted by another teammate's appointments. Google Drive, by contrast, is per-workspace: the Owner connects one Drive account from Settings, and that Drive becomes the destination for every member's Save to Drive action and every module-level auto-provision. Different teammates do not connect their own Drives; the workspace has exactly one Drive at a time.

Connecting Google Calendar from My Profile

Open My Profile, scroll to the Calendars card, and click Connect Google Calendar. You will be redirected to Google's OAuth consent screen where you sign in (if not already signed in) and review the permissions the platform is requesting (read your calendars, write events, see your email address so we can label the connection). Approve; you are bounced back to My Profile with the new calendar listed as your Primary calendar (if it is your first connection) or as your Secondary calendar (if you already had one). The platform stores an encrypted refresh token so you do not have to re-authenticate on every render; the access token rotates automatically in the background.

Primary versus Secondary calendar

Each member can connect up to two calendars. The first connection you make is your Primary; subsequent connections (a different Google account, a Microsoft 365 Outlook calendar) become Secondary. The Primary calendar receives the full event on every confirmed booking, Q&A session, and Let's Coordinate meeting (with attendees, with the Google Meet link, with the description). The Secondary calendar receives a busy-block mirror after every booking (no attendees, no conferencing, simply marked busy) so you see the slot occupied on both calendars. Both calendars contribute freebusy intervals to your booking page availability check, so a meeting on your Secondary will block your Primary's slot from being offered to clients.

Promoting the Secondary to Primary is a one-click action on the Calendars card. The platform handles the role swap atomically (an internal database function executes the swap in a single transaction so no booking lands on the wrong calendar mid-swap). After a swap, new bookings start landing on the new Primary; existing bookings on the old Primary continue to live there but stop receiving updates from the platform (the platform only writes to the active Primary).

Google Meet on confirmed bookings

When your Google account is a Workspace account (a paid Google Workspace tier with Meet enabled) and your service is configured as an online or hybrid format, the platform asks Google to provision a Meet link at the moment it creates the calendar event. Google returns the Meet URL synchronously in some cases and asynchronously in others; the platform handles both, falling back to a defensive re-fetch when the link is missing on the initial response. The Meet URL appears on the confirmation email the client receives and on the calendar event itself. Personal Gmail accounts do not get a Meet link from this flow; the platform degrades gracefully (calendar event still creates, you arrange the meeting URL out of band).

Connecting Google Drive from Settings

Open Settings, scroll to the Integrations card, and click Connect Google Drive. Same OAuth posture as the calendar connection: you sign in to the Google account that should own the Drive folder tree (typically the firm's shared account, not a personal one), you review the permissions (the platform requests only the scope it needs to create folders and upload files; it does not request access to your existing Drive contents outside the folders it itself creates), and you approve. The platform creates a root folder named RCIC App on your Drive at the moment of first use, and every module-level folder lives under that root.

The RCIC App folder tree on your Drive

The platform organises everything it writes to your Drive under the RCIC App root folder. Inside it: Transfer Rooms appear as Clients / <client name> / <agreement reference> / (Contract / Pre-contract consultation / Client Docs / RCIC Docs / Application / Government Communications / Identification), Ad-hoc Transfer Rooms appear under Ad-hoc Transfer Rooms / <room name> / <YYYY-MM-DD>, Secure PDF Tools output appears under Secure PDF Tools / <YYYY-MM-DD>, and PDF Sign signed envelopes appear under Secure PDF Tools / Signed PDF files / <YYYY-MM-DD>. The platform never writes outside its root folder; you can browse, organise, and back up the contents of the RCIC App folder just like any other folder on your Drive, but the platform's automation lives entirely within it.

Scopes and permissions

Calendar uses the minimum read and write scope needed for the booking + freebusy flow. Drive uses the drive.file scope, which is deliberately narrow: it only lets the platform create and modify files and folders it itself created, not your existing Drive contents. The platform cannot read your private documents, cannot list folders it did not make, and cannot access anything outside the RCIC App root folder. This is the principle of least privilege: even if a hypothetical platform compromise occurred, the blast radius would be limited to what the platform created in the first place.

Google Cross-Account Protection (RISC)

The platform participates in Google's Cross-Account Protection programme (RISC). When something significant happens to your Google account upstream (the account is disabled by Google, your sessions are revoked, your credentials are forced to reset, your tokens are revoked through a Google security alert), Google pushes a signed security event to the platform within seconds. The platform verifies the signature against Google's public key set, acts on the event by flipping your Drive connection state to Reconnect required, and emails the Owner so you know to expect Drive operations to start failing until you reconnect. This is real account-takeover protection: a stolen Google account refresh token cannot continue to write to your Drive once Google revokes it because Google's revocation event reaches the platform proactively.

The Reconnect required banner

If a refresh token goes stale for any reason (your Google password changed, multifactor authentication was reset, the connected account was disabled, or RISC fired a revocation), the connection card flips to an amber Reconnect required state. The Calendars card on My Profile shows the banner per calendar; the Integrations card on Settings shows the banner for Drive. Save to Drive across every module degrades gracefully in the meantime: bytes that would have routed to Drive stay queued and retry automatically once you reconnect; no file is silently lost. Click Reconnect; the OAuth flow runs again; the connection returns to green and queued items drain.

Disconnecting

Disconnect Google Calendar from the Calendars card on My Profile; the platform clears its stored tokens immediately and the calendar stops appearing in your booking page availability check. Disconnect Google Drive from the Integrations card on Settings; the platform stops writing new files to the Drive folder but the existing folder tree and its contents stay on your Drive (the platform never deletes Drive content on disconnect, since you may want to keep the historical files even if you intend to stop using the integration). Calendar disconnect is per-member; only that teammate's calendar is affected. Drive disconnect is workspace-wide; every member's Save to Drive action stops until reconnected.