Onboarding and offboarding from approved requests: account integrations for Microsoft 365, Google Workspace, Okta and SnagBane

When a new-starter or leaver request is approved, SnagBane can now do the account work itself. It can create the account, change a name or sign-in address, block someone who leaves and sign them out everywhere, or restore an account. This works in Microsoft 365, Google Workspace, Okta and SnagBane. Accounts are never deleted, and administrator accounts are never changed. The account integrations are part of the Enterprise plan.

Most companies already run onboarding and offboarding as a request: HR or a manager fills in a form, someone approves it, and then IT does the account work by hand. That last step is where things slip — the leaver who can still sign in a week later, the new starter waiting for a password on day one. With the account integrations, the approval itself triggers the change, and the request, the decision and the account change end up in one audit log.

What each integration can do

New accounts get a temporary password that must be changed at the first sign-in. SnagBane emails it only to the address you choose — usually the hiring manager or IT. It is never shown in SnagBane, in the run log or in the audit log.

The guardrails

Integrations that change real accounts need firm limits, so these rules are built in and can't be switched off:

• Accounts are never deleted. Offboarding means blocked or suspended; you can restore the account later. Okta accounts are suspended, never deactivated.
• Administrator accounts are never changed. SnagBane refuses anyone with a Microsoft Entra admin role, a Google Workspace super or delegated admin, anyone with a Google admin role assignment, anyone with an Okta admin role — also when the role comes through a group. SnagBane owners, administrators and user & access admins are refused too.
• If the admin check fails, nothing changes. When SnagBane can't confirm that someone is not an administrator, it stops and says why.
• Groups that hold admin roles are refused, so nobody can be added to an admin group through a form.
• Domains are typed by an administrator. New and changed sign-in addresses must use the domain set in the integration, never one taken from an answer. A form answer can't point an account at an outside address.
• Only administrators and owners can set them up. User & access admins and editors don't see them in the catalog.
• Nothing runs until it's confirmed. Each integration runs After approval by default and stays off until an administrator ticks I understand that this integration changes real accounts. Send test only checks the settings and looks the person up — it never creates, changes or blocks anything.
• Everything is audited: account.created, account.updated, account.switched_off and account.switched_on, with the form, the response and the integration.

SnagBane also shows a red warning on the category, on each integration and at the top of its settings, and next to the permission in Settings → Microsoft 365 and Settings → Google Workspace.

How to set it up

1. Give SnagBane the permission it needs.

• Microsoft 365: in Settings → Microsoft 365, click Re-run setup / change permissions and tick Create and switch off accounts.
• Google Workspace: in Settings → Google Workspace, tick Create and switch off accounts. With a service account, add its scopes to domain-wide delegation.
• Okta: grant okta.users.manage, okta.groups.manage and okta.roles.read to the API Services app from Settings → Okta. Then give that app an admin role that covers your staff and can read admin roles — for example a custom admin role with manage users, manage group members and View roles, resources, and admin assignments (permissions of the role, not API scopes). Super Administrator isn't needed.

1. Use a form with an approval step: a new-starter form, a leaver form, or a change request. A person question for whose account works best, because it holds exactly one address.
2. Add the integration to the form (Integrations → Accounts), choose what it does — create, change, block or restore — and insert the form's questions: first and last name, manager, job title, department.
3. Tick the confirmation, keep After approval, and click Send test. Then try it once with a test account before you use it for real people.

The documentation has the setup guide for each integration.

A typical leaver process

1. The manager fills in the leaver form and picks the person in the people picker.
2. HR approves, then IT approves.
3. After the last approval, SnagBane blocks the Microsoft 365 account, revokes every session and removes the licences. It also switches off the person's SnagBane account.
4. The run log shows what was done, and the audit log keeps the request, both approvals and the account change together.

The new-starter process works the same way the other way round. The new-starter onboarding guide shows a complete form with equipment and access requests.

Frequently asked questions

Which plan includes the account integrations?

The Enterprise plan. They belong to the security package together with SIEM forwarding, SCIM, the IP allowlist, data retention and automatic offboarding.

Can someone use a form to take over an administrator account?

No. Administrator accounts are refused in every directory and in SnagBane. If the check can't be completed, nothing is changed. New and changed addresses must also use a domain that an administrator typed into the integration.

Does SnagBane delete accounts?

Never. Offboarding blocks or suspends the account, so you can restore it later, for example when someone comes back.

How is this different from SCIM?

SCIM syncs accounts from your directory into SnagBane. The account integrations go the other way: an approved SnagBane request creates or changes the account in your directory.

Who receives the temporary password?

Only the email address you choose in the integration, such as the hiring manager or the IT team. It must be changed at the first sign-in, and it never appears in SnagBane or its logs.