Google Workspace Integration for ABA Employee Lifecycle

An RBT gives two weeks' notice on a Friday. HR updates the payroll system. The clinical director reassigns caseloads. Nobody tells IT — because there is no IT, there is an office manager with admin rights — and the employee's Google account stays active for another month, still receiving faxes forwarded to a shared inbox, still a member of the parent-communications group.

This is the most common HIPAA exposure in small and mid-sized ABA organizations, and it has nothing to do with encryption. It is an account lifecycle problem. This guide explains how Google Workspace for therapy centers should be wired into employee onboarding and offboarding, and how TargetFlo's live Google Workspace integration does it.

What is employee lifecycle management for Google Workspace?

Employee lifecycle management is the practice of creating, changing, suspending, and eventually removing a person's accounts in step with their employment status. For a Google Workspace organization that means: provisioning the account when the hire is confirmed, placing it in the right organizational unit so the correct policies apply, adjusting it when the role or location changes, suspending it the moment employment ends, and reactivating it if the person returns.

Done manually, each step is a ticket someone might forget. Done as an integration, each step is a consequence of a status change on the employee record.

The five lifecycle events and what should happen in Workspace

TargetFlo's Workforce module exposes provision, suspend, and reactivate as actions on the employee record, with org unit assignment driven by role and location. The account's email lifecycle — created at onboarding, suspended at offboarding — follows the employee's status rather than a separate to-do list.

Why org units matter more than most centers realize

Google Workspace applies most security policies at the organizational unit level: two-step verification enforcement, Drive sharing restrictions, whether Gmail can forward externally, device management rules. An account placed in the default OU inherits whatever the default allows.

For an ABA center, a sensible OU structure separates roles with different PHI exposure:

• Clinical staff (BCBA, RBT, BT): external sharing off, forwarding off, 2SV enforced
• Intake and front office: same restrictions, plus membership in fax and referral groups
• Administration and billing: access to finance shared drives, stricter device rules
• Contractors and external providers: minimal scope, time-boxed

When the OU is assigned automatically from role at provisioning time, every new hire lands in the correct policy scope on day one. When someone moves from RBT to intake coordinator, the OU changes with the role change on the employee record instead of waiting for someone to notice.

Onboarding: provision after the paperwork, before the first session

The order of operations on a new hire should be deliberate:

1. Offer accepted; employee record created in the directory with role and location.
2. Consents and SOPs for that role are assigned for e-signature.
3. Google Workspace account is provisioned into the role's org unit.
4. Onboarding courses become available in the employee's training queue.
5. Training completion and signed policies gate the first client-facing shift.

Step 3 sits after step 2 for a reason. Provisioning an account for someone who has not yet acknowledged the HIPAA policy creates a window in which they could receive PHI without having agreed to how it must be handled. Tying account creation to the employee record makes the ordering enforceable. For the training side of this sequence, see Workforce Training & Compliance for ABA Organizations.

Offboarding: suspend, do not delete

The instinct on departure is to delete the account. Resist it. Deletion destroys email history and Drive files that may be needed for records retention, ongoing client matters, or a dispute about what was communicated to a family.

Suspension is the correct first action. A suspended Google account cannot sign in, does not receive mail, and drops out of groups, but its data remains intact. From there, the organization can transfer Drive ownership, set up email delegation for a supervisor, and delete after the retention period. In TargetFlo, marking an employee as offboarded triggers suspension; the account is not removed until an administrator explicitly chooses to.

The offboarding checklist that usually gets skipped

• Remove the person from shared fax and referral distribution groups
• Revoke access to shared drives holding client documents
• Transfer calendar ownership for any recurring parent meetings
• Confirm no personal device still has a synced work account
• Record the suspension date on the employee record for audit purposes

Reactivation without duplicate identities

Seasonal staff, returning BTs, and re-hired RBTs are common in ABA. Creating a second account for a returning employee fragments their history and leaves an orphaned first account sitting in suspension forever.

Reactivating the original account restores email continuity and keeps one identity per person. The employee record in TargetFlo retains their prior training and consent history, so re-verification is a matter of checking what has expired rather than starting from zero.

Where this fits in the broader integration picture

Google Workspace is one of several integrations TargetFlo runs live today, alongside RingCentral fax, Stedi-compatible eligibility checks, and Gemini-powered OCR — the full list is on the Integrations hub. For Microsoft-first organizations, TargetFlo is building an equivalent Entra ID lifecycle integration; it is on the roadmap with a waitlist, and we compare the two ecosystems in Microsoft 365 for Therapy Centers: What Operations Teams Need.

The principle behind all of it

Account access should be a property of employment status, not a separate system administered from memory. When the employee record is the source of truth and Workspace follows it, onboarding is faster, offboarding is immediate, and the audit question "who had access to what, and when?" has a single answer.