Reference · built on requestOperator by FibricIT & reliability

Offboarding Sweep

On a termination in HR, lists every account and owned asset the leaver still holds and proposes each deactivation and transfer.

Request accessPricing ↗

About

The termination is recorded in HR on Friday. The GitHub seat, the Google Drive full of contracts, and the Okta session are still there on Monday. Offboarding Sweep listens for leaver events, whether worker changes with an offboarding in Rippling, employees marked Deleted in BambooHR's changed feed, or a termination in Workday, and then walks the systems: the user's Okta status and app assignments, the Google Workspace account with its Drive and Calendar data, membership of GitHub organizations, and the Entra ID account.

It produces one checklist per leaver with a proposal per line: deactivate here, sign out there, transfer Drive ownership to the manager, remove from the organization. Every line waits for approval by the person you name, usually the manager plus IT. The record shows what was done, when, and by whom, in the order it happened.

This is a reference listing. It documents what Fibric would read from Offboarding Sweep and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Worker changes with effective_on and applied_on timestamps from Rippling, including offboardings
  • Employees changed since a timestamp from BambooHR, marked Inserted, Updated, or Deleted, and termination events from Workday's Staffing service
  • The leaver's Okta user with lifecycle status, group memberships, application assignments, and active sessions
  • The Google Workspace user with suspended, lastLoginTime, and orgUnitPath, and the applications available for data transfer
  • Membership of your GitHub organizations and teams, checked through the members endpoints
  • The Microsoft Entra ID user with accountEnabled, group memberships, and assigned licenses
  • Sign-in attempts and item usage for the leaver from 1Password, in the days around the exit

Proposed actions

  • Target capability: propose Deactivate a user and Clear user sessions in Okta on the effective date
  • Target capability: propose suspending the Google Workspace user, calling users.signOut, and inserting a Data Transfer from the leaver to the manager for Drive and Calendar
  • Target capability: propose removing the leaver from each GitHub organization through DELETE /orgs/{org}/members/{username}
  • Target capability: propose setting accountEnabled to false and removing licenses on the Entra ID user
  • Target capability: propose the checklist as a message to the approvers with one approve control per line

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Sweep a leaver across four systems

    Rippling records an offboarding effective Friday. The checklist proposes Okta deactivation, Google suspension with a Drive transfer to the manager, and removal from two GitHub organizations, each approved by IT and applied in order.

    With Rippling, Okta, Google Workspace, GitHub

  • Return the licenses with the account

    BambooHR marks the employee Deleted. The operator proposes accountEnabled false on the Entra user and removeLicenses for each assigned SKU, so the seat is free the same day.

    With BambooHR, Microsoft Entra ID

  • Check what was touched on the way out

    1Password item usage in the leaver's final days is listed beside the checklist. Shared vault items that were exported or copied are called out for the manager to review.

    With 1Password, Slack

Requirements

  • An HR connector that emits leaver events with an effective date: Rippling worker changes, BambooHR changed employees, or Workday
  • Okta scopes okta.users.manage and okta.sessions.manage, or an SSWS token with the same rights, for deactivation and session clearing
  • A Google Workspace service account with domain-wide delegation for the admin.directory.user and admin.datatransfer scopes
  • A GitHub App or token belonging to an organization owner, since only owners can remove members
  • Microsoft Graph User.ReadWrite.All and LicenseAssignment.ReadWrite.All for disabling the account and returning licenses
Authentication
Offboarding Sweep carries no tokens. Leaver events come through your HR connector, and every deactivation or transfer is applied by the Okta, Google Workspace, GitHub, or Microsoft Entra ID connector under the scopes granted to it.

Limits

  • Leaver events arrive when HR records them. A termination entered late is swept late; the operator cannot see an exit HR has not recorded.
  • Removing a GitHub member ends direct membership only; access held through an enterprise team persists and is listed for a human.
  • A Data Transfer moves ownership through the applications Google lists for it; content outside those applications is not transferred.
  • Every line is a proposal. Nothing is suspended, signed out, or transferred until the named approver acts on that line.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Offboarding Sweep ↗

Questions and answers

Who approves what?
You name approvers per system, usually the manager and IT. Each checklist line names the account, the action, and the connector that will apply it. A line is applied only when its approver confirms it, and lines can be approved out of order if needed.
What record survives the offboarding?
A per-leaver ledger: the HR event that started it, each proposed line, who approved it, the timestamp the connector applied it, the API result, and the transfer ID for Drive. It is the evidence an auditor asks for.
What will it never do by itself?
It never deactivates, suspends, or removes anyone without an approval on that line, and it never deletes accounts or data. Deletion, where you want it, is a separate manual step after the retention period you set.
Ask about Offboarding Sweep

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy