Overview
When someone leaves your organization — or should simply no longer reach your social accounts — removing their Spikerz login is only one part of the job. Offboarding is complete when four separate layers of access are closed.
Layer | Question | Where you handle it |
Identity | Who is the person? | Your Identity Provider (Okta, Microsoft Entra ID) |
Spikerz seat | Can they log in to Spikerz, and with which role? | Settings > Members, or the Permissions page |
Asset & collection assignment | Which social accounts and collections can they open in Spikerz? | Settings > Members > Edit Assets |
Native social permission | What access do they actually hold on the platform itself? | Permissions (Asset permissions) |
The most common offboarding mistake: assuming that disabling the corporate identity removes social access. It does not. Native platform permissions and shared credentials survive an IdP disable — and that gap is exactly what lets a former employee or ex-agency keep posting.
Spikerz closes the two middle layers in a single action. See Remove the user in one step below.
Manual vs. SCIM at a glance
| Manual offboarding | SCIM offboarding |
What starts it | An Admin removes the user from the Permissions page or from Settings > Members | Deactivating or unassigning the user in your IdP |
Spikerz seat & collections | Revoked with the Revoke Spikerz seat option in the Remove dialog | Revoked automatically |
Native platform roles | Revoked with the Remove native roles option in the same dialog | Removed automatically where supported — only after Spikerz support enables automatic revocation for your workspace |
Former Employee status | Not applied | Applied automatically on the Permissions page |
Detection-only platforms | Manual, in the platform's own console | Manual — Spikerz notifies Admins what is left to remove |
Typical time to revoke | Depends on Admin availability | Minutes after IdP deprovisioning |
Best for | Workspaces without an IdP integration, and anyone outside the directory: contractors, agencies, partner and system users | Enterprise workspaces with Okta or Azure and employee turnover at scale |
Even with SCIM enabled, the manual steps below remain the reference for anything SCIM cannot reach.
Before you start
You need the Admin role in Spikerz.
Know whether SCIM is enabled for your workspace. If you are unsure, check with your Spikerz contact or look for the Spikerz app in your IdP's provisioning configuration.
Have a short list of everything the person could reach: Spikerz assets and collections, native platform permissions, shared credentials and recovery details.
If SCIM is enabled, confirm the user is matched to a Spikerz member on the Permissions page. Matching is what links the corporate identity to their social accounts, and it enables access control regardless of their protection status.
Option A: Manual offboarding
Use this path when SCIM is not enabled, and for any user who does not exist in your IdP.
Step 1: Remove the user in one step
You can start the removal from either place:
Permissions page — go to All assets > Asset permissions (or a single asset's Asset Permissions view), find the person, and choose Remove.
Members page — tap the top-right profile icon > Settings > Members, find the person, and choose Remove.
Both open the same Remove dialog, which asks you to select what to revoke. Two options are available, and both are selected by default:
Option | What it revokes |
Remove native roles | The native platform roles Spikerz detected for this person. The dialog shows the scope — for example, 4 assets (Facebook Pages, Meta, LinkedIn) — so you can see exactly what is about to be removed. |
Revoke Spikerz seat | Their access to the Spikerz platform, including every collection they belong to — for example, Remove from workspace & 14 collections. |
Review the counts, then click Remove.
When to leave one option unchecked
Employee leaving the company — keep both selected. This is the full offboarding case.
Keeping the seat, removing social access — leave only Remove native roles selected. Useful when the person moves to a role that no longer needs platform access but still works in Spikerz.
Native access handled by another team — leave only Revoke Spikerz seat selected, then track the native removal separately. Be explicit about who owns it: an untouched native role is the access that outlives the offboarding.
Step 2: Finish the platforms Spikerz cannot revoke for you
The Remove dialog acts on everything Spikerz can revoke on your behalf. Where a platform is detection only, Spikerz shows you the access but the removal happens in the platform's own console.
Platform | Detection | Removal from Spikerz |
Facebook Pages | Yes | Yes — effective immediately |
Meta | Yes | Finish in Meta Business Suite where the role remains |
Yes | Finish in the platform | |
Yes | Finish in the platform |
After removing access in a platform's own console, return to the Permissions page and confirm the person no longer appears on that asset.
Step 3: Update your approved user list
A departing employee should no longer be an approved user. Anyone who holds access but is not on the approved list is flagged with an Unauthorized User badge, so if the person regains access outside Spikerz, you will see it.
To close this automatically, open an asset's Asset Permissions > Settings tab, enable Unauthorized User Alerts with automatic removal, and use Apply to all assets so the rule covers your whole environment.
Step 4: Close shared and recovery access
Access that is tied to a person rather than to a login also needs attention:
Secured email and secured phone — make sure recovery details for the accounts they touched are centralized in Spikerz rather than pointing at the individual.
2FA — confirm no critical account depends on the departing person's device.
Shared credentials and password rotation — rotate anything they knew, using Account Lockout and password rotation rules where enabled.
Step 5: Verify nothing is left
On the Permissions page, search the person's name and email and confirm no assets remain in either User view or Asset view.
Check Activity Logs to see the removal events recorded on your workspace timeline.
Re-check after the next permissions scan — access granted outside Spikerz can reappear.
Role changes instead of removal
When the person is staying but their responsibilities change, narrow their access instead of removing them:
Use the role dropdown next to their name in Settings > Members to move them to Member, Community Manager or Viewer. You will then be prompted to select which accounts they keep.
Use the "..." menu > Edit Assets to remove individual social accounts. Changes apply instantly.
Then run Step 1 with only Remove native roles selected if their platform-side access should also go.
Option B: SCIM offboarding
With SCIM, offboarding starts in your IdP and Spikerz follows automatically.
Prerequisites
SCIM 2.0 provisioning is configured against the Spikerz SCIM endpoint, with the token Spikerz provided.
The unique identifier is the user's email, so corporate email values must be consistent between your IdP and Spikerz.
Users are assigned through Spikerz groups whose suffix sets their role (-admins, -members, -viewers, -community-managers) and those groups are pushed to Spikerz.
The user accepted the app invitation email at least once — provisioning does not apply to users who never did.
The user is matched to their social accounts on the Permissions page.
Automatic removal from social accounts is enabled on request
Deprovisioning through SCIM always revokes the Spikerz seat. Having Spikerz also revoke the person's native access on your social accounts automatically is a separate, opt-in capability.
Because it acts directly on your live social assets, Spikerz turns it on per workspace after a short conversation with Spikerz support — so that the scope, the platforms in play and the approval path are agreed before anything is removed automatically.
It is the strongest control in this article: once enabled, a departing employee loses social access at the moment their identity is deprovisioned, with no admin in the loop. If you want it on, contact your Spikerz contact or support to open it for your workspace. Until then, use Remove native roles in the Remove dialog (Step 1 above) after each deprovisioning.
What happens when you deprovision
In Okta or Azure / Microsoft Entra ID, deactivate the user or remove them from the Spikerz groups, per your company policy.
Spikerz receives the SCIM event and revokes their Spikerz seat.
The user is flagged Former Employee on the Permissions page.
If automatic removal is enabled for your workspace, Spikerz revokes their native access on the supported platforms — Facebook assets today.
Admins are notified to remove the access Spikerz cannot revoke on their behalf.
What still needs a human
Native roles, if automatic removal is not enabled for your workspace — use Remove native roles in the Remove dialog.
Detection-only platforms: Instagram, LinkedIn and Meta Business Suite — finish those removals in the platform itself (Step 2 above).
Shared credentials, recovery email and phone, and 2FA (Step 4 above).
Anyone who is not in your IdP: partner users, system users and private users. See the section below.
Verify
On the Permissions page, confirm the Former Employee badge and an empty asset list for that person.
Confirm the deprovisioning event and any automatic removal in Activity Logs.
If any native role is still listed, open the Remove dialog on the Permissions page and use Remove native roles to close it.
Contractors, agencies and system users
SCIM only covers identities that exist in your IdP. Partner users (agencies and third-party providers), system users (integrations and automation) and any private user outside the directory always follow the manual path.
Apply the same offboarding process when an agency, contractor or vendor relationship ends, and review system users so that automation access does not outlive the project it was created for.
Common gaps and how to close them
Symptom | Likely cause and fix |
Removed from Spikerz, but the person can still post | Only Revoke Spikerz seat was selected in the Remove dialog, or the role sits on a detection-only platform. Re-open the dialog and use Remove native roles, then complete Step 2. |
SCIM revoked the seat, but native social access is untouched | Automatic removal from social accounts is probably not enabled for your workspace. Contact Spikerz support to open it, and use Remove native roles in the meantime. |
IdP deactivation did not reach Spikerz | Check that the email matches on both sides, that the user is in a pushed Spikerz group, and that they accepted the app invitation. |
Former Employee is shown, but access remains on Instagram or LinkedIn | Those platforms are detection-only. Remove the access in the platform. |
The user reappears on an asset after removal | Access was re-granted natively, outside Spikerz. Enable Unauthorized User Alerts with automatic removal. |
You are not sure what the person could reach | Open the Remove dialog and read the two counts before confirming, or use Asset view on the Permissions page and filter by user, platform and access role. |
Offboarding checklist
Disable the corporate identity per company policy — via SCIM deprovisioning where available.
Open the Remove dialog from the Permissions page or Settings > Members and confirm with both options selected: native roles and Spikerz seat.
Review the remaining native permissions on detection-only platforms and remove them there.
Remove the person from your approved user list.
Review shared credentials, recovery email and phone.
Review 2FA and recovery access.
Confirm in Permissions and Activity Logs that no residual access remains.