What this is. The recommended order of operations for rolling Spikerz out across an enterprise.

The goal. Spikerz becomes part of your existing identity, access-management and security operations.

Every employee gets access to only the social assets their role requires.

How to use it. Work through steps 1 to 13 in order.

Each step says what to do, what to watch out for, and where the detailed instructions live.

Steps 1 and 2 are usually IT and security. Steps 3 to 7 are usually done jointly with the social and marketing owners.

The one rule that matters most

Connect and assign assets before onboarding the broader team.

Adding someone to Spikerz can give them access to connected social accounts, so decide asset access first, not later.

Configure enterprise plumbing before anyone else is onboarded.

Depending on your environment this covers SSO, SCIM, your identity provider, SIEM, and notification tooling.

Everything supported is listed under Integrations.

Configure SSO before onboarding the broader user base, so Spikerz access follows your existing authentication policies.

Spikerz recommends:

Where the instructions are:

Two things to get right:

Aligning session length with your session-lifetime policy? See how the SAML SessionNotOnOrAfter assertion is handled here.

Before SSO is live, your first few admins will log in directly.

See the sign-up and login process and account setup by invite.

Best practice

The Name ID value is not just an SSO setting.

It is the key that lets Spikerz reconcile a corporate identity with a social-platform user in step 7. Getting it wrong here means identity matching quietly fails later, and the cause is hard to trace back.

Use SCIM for the user lifecycle, meaning provisioning and deprovisioning employees.

Provisioning someone into Spikerz is not authorization to every connected social asset.

Keep three controls separate:

Setup: turn provisioning to SCIM 2.0, point it at the Spikerz SCIM endpoint with the token Spikerz provided, select all provisioning actions, and set the unique identifier to email.

The Entra ID article covers this in section 4.1.

Best practice

Treat SCIM as answering one question only: who should exist in Spikerz.

The most common enterprise mistake is letting provisioning imply authorization, which quietly grants new joiners access to social accounts nobody reviewed.

Feed Spikerz security activity into your existing SOC monitoring and incident-response processes.

Start with the SIEM overview here.

By platform:

Have your SOC review the payload schema, exact event names, recommended severities and correlation logic before they write anything.

See the full alert and event reference here.

Best practice

Review the event reference before your SOC builds detections, not after.

Detections written against guessed event names have to be rebuilt once real events start flowing, and the rework usually lands in the middle of go-live.

Route security notifications to the channels your team already watches.

See how to connect Slack and Teams here.

Best practice

Send day-to-day triage to Slack or Teams and formal incidents to the SIEM.

Start with a handful of people, not the whole organization.

Include:

This group configures the environment before anyone else gets access.

Before you assign anyone, review what each role can actually do so the first admins are scoped deliberately.

See the roles and permissions model here.

The mechanics are covered in adding admins and members.

Wider configuration options live under Workspace & Settings.

Best practice

Keep this group to four or five people, and give them full admin only for the duration of the rollout.

Connect the accounts before onboarding the broader user base.

Connected accounts become the assets you assign to users in step 4.

Connect first, then assign.

List every corporate social account that should be protected: Facebook, Instagram, LinkedIn, TikTok, YouTube, X and any other supported platform.

Protections are not identical on every platform, so check what is actually available before you finalize scope.

See the platform-by-platform feature availability here.

For each account, document:

Each platform models access and ownership differently, which changes how you read what you find.

See how the major platforms structure access here.

See the general connection process here.

Confirm that:

The fastest way to check is to review which tokens and assets are registered and healthy.

See the token inventory here.

General onboarding material sits under Getting Started.

A mandatory access-control step before onboarding the broader team.

Security principle

A user should only have access to the social assets required to perform their responsibilities.

Adding someone to Spikerz can give them access to connected social assets.

Do not add users broadly and decide asset access afterwards.

The token inventory is the authoritative list of what is connected.

For every asset, identify the social media owner, marketing users, administrators, security users needing operational access, agencies, contractors and any other external users.

Assign only the relevant assets to each user.

Avoid "All Assets" as a default.

Managing a large estate? Grouping accounts avoids the choice between per-asset tedium and over-broad access.

See how to organize assets into collections here, and how aggregation mode centralizes monitoring across every connected asset here.

Check all three, in order:

Identity → Spikerz Role → Assigned Social Assets

Only when all three are correct should the user receive access.

Best practice

Build asset groupings around who needs access, not around how marketing organizes campaigns.

Collections that mirror the marketing calendar have to be rebuilt every time a campaign ends. Collections that mirror ownership stay accurate for years.

Role and asset assignment are two separate decisions. Both follow least privilege.

Using group-based authorization? Map these personas onto the Spikerz groups described in your IdP integration article: spikerz-security-admins, spikerz-marketing-admins, spikerz-viewers, spikerz-community-managers and equivalents.

Agree membership and get manager approval before provisioning.

If the answer to #4 is no, do not grant admin.

Best practice

Security and SOC users need visibility, not asset access.

Granting the security team every social asset by default is a common shortcut, and it defeats the access model you just built. Give them monitoring scope and add specific assets only where they run operational tasks.

This produces your approved-access baseline, which is the thing automation will later enforce.

Spikerz shows who holds access across your brand's social assets and lets you revoke risky access fast.

See how to use permissions management here.

Read the results carefully, because a "role" on one platform is not equivalent to the same label on another.

The target state is that access visible in the social environment matches your approved access model.

For supported Facebook assets, Spikerz can automatically remove users who are not on the approved list.

See how to configure auto-remove here before enabling it.

Related material sits under Permissions & Access Management.

Order of operations, important

Add approved users to the Approved Permissions List in Spikerz before granting them access on Facebook.

Otherwise Spikerz may read them as unauthorized and remove them automatically.

Best practice

Do the cleanout with the social team in the room, not as a security exercise done to them.

They are the only people who can tell you whether an unfamiliar account is a legitimate agency contact or genuinely unknown, and doing it together avoids revoking access that a live campaign depends on.

The question this answers: who is this social media user inside our organization?

Matching relevant users against your IdP gives you a clear chain:

Corporate Identity ↔ Employee ↔ Spikerz User ↔ Social Asset Access

What makes it work is consistent corporate email values, since the SCIM unique identifier is the user's email.

An unmatched user is not automatically malicious. It may be:

Every one still needs a decision: map it, explicitly approve it, or remove it.

Best practice

Document your approved exceptions somewhere durable, with an owner and a review date.

Unmatched users that are legitimately external will reappear at every audit. Without a recorded decision, each review starts the same investigation from scratch.

Extend protection from the corporate asset to the people whose accounts can reach it.

Administrators start with the employee protection and access admin guide, which also covers controlled offboarding.

Employees complete a short setup themselves.

See the employee-side installation steps here.

Meta Business Suite in scope? See how employee protection applies to it here.

Best practice

Lead the employee rollout with what it does not do.

Employee Protection secures social access used for work without taking personal control of the account, and saying that clearly upfront prevents the resistance that otherwise stalls enrollment.

Centralize recovery, 2FA and access monitoring so no critical account depends on one individual.

Everything here sits under Account Protection.

Work through it in this order.

Replace employee-dependent recovery details with the Spikerz-provided secure email.

This centralizes recovery details and insulates them from phishing, scams and employee turnover.

See how to use the secured inbox here.

Recovery mailboxes are themselves a target.

See how the email risk scanner detects phishing and scam attempts here.

The goal is that no critical social account depends on an individual employee's personal phone number.

See how to keep phone and email details current in Spikerz, so alerts, verifications and recovery messages reach the right place.

See how to change these details on the platforms, and on LinkedIn specifically.

Spikerz can centralize 2FA access so authorized team members do not depend on one person's authenticator device.

This is the single most common way organizations lose access to their own accounts.

Store recovery codes in Spikerz so the organization holds controlled access to recovery, rather than individual employees.

See how to find or reset a social media password.

For security review or architecture sign-off, see the enterprise password security briefing.

Automated defense rules and scanning against unauthorized access.

See how account lockout works here.

Per-platform hardening sits under Securing Your Social Platforms.

Best practice

Test recovery on one low-risk account before rolling this out everywhere.

Recovery configuration is only proven by using it. Discovering that a protected phone or backup code does not work during a real incident is the worst possible time.

The account is not the only attack surface.

The comment and follower layer of a corporate account is routinely used for scam links, impersonation, credential phishing aimed at your customers, and coordinated inauthentic engagement.

These are security problems that happen to appear in a marketing surface, so configure them during onboarding rather than later.

Hostile links and scam replies under a brand post reach your customers carrying your brand's implied endorsement.

Comment hygiene is a customer-protection control.

Bot followers distort the audience data your team reports on, and are frequently the delivery mechanism for spam and phishing aimed at your real followers.

Unexplained reach loss can indicate a platform-level restriction rather than a content problem.

Rule it out during onboarding so you start from a clean baseline.

See how to use the shadowban tool, with further detail here.

More sits under Comments & Content Moderation.

Best practice

Export the follower list before any bulk bot removal.

Removal at scale is hard to reverse without a record of who was there beforehand, and the export gives you both a rollback path and an audit trail.

Enable automation only after the approved baseline is validated.

Otherwise legitimate users get caught by your own security rules.

Unapproved user gains access → detect → revoke

Confirm the approved-user list is complete first.

Unknown or unauthorized login → alert or revoke per policy

See how alerts surface.

Removed from approved structure → remove unnecessary social access

Unexpected privileged-access change → detect → investigate or remediate

See every action and alert in one timeline.

Start with the highest-confidence rules, validate approved users and identities, then enable automatic remediation.

Automation enforces the access model you defined during onboarding. It does not replace defining it.

Best practice

Run each rule in alert-only mode for a week before letting it remediate.

A week of real traffic surfaces the legitimate edge cases, such as agency accounts and shared logins, that a policy review on paper always misses.

Best practice

Test the negative cases, not just the positive ones.

Confirming that an approved user can log in proves very little. Confirming that a deprovisioned user cannot, and that a marketing user cannot reach an asset they were never assigned, is what actually validates the model.

Once validation passes, the environment moves into normal operation.

The production model:

Corporate Identity / IdP ↓ SSO + SCIM ↓ Spikerz User + Role ↓ Explicit Social Asset Assignment ↓ Connected Social Accounts ↓ Permissions + Employee Protection ↓ Account Takeover Protection ↓ Content & Engagement Security ↓ Automation & Remediation ↓ Security Monitoring / SIEM

Do not just connect it and consider it protected.

Every new account follows the same process.

Best practice

Treat a newly acquired or inherited account as untrusted until step 4 is done.

Accounts that arrive through an acquisition, an agency handover or a departing employee almost always carry access nobody has reviewed, and connecting them does not remove it.

A new employee does not automatically inherit access to all Spikerz assets.

The employee should only see the assets their responsibilities require.

Best practice

Add the person to the approved permissions list before granting them native platform access.

Doing it in the other order means your own automation may remove them within minutes, which reads to the new joiner as a broken system.

When someone leaves or changes responsibilities:

Apply the same process when an agency, contractor or vendor relationship ends.

Best practice

Deprovisioning the corporate identity is not the same as removing social access.

Native platform permissions and shared credentials survive an IdP disable, which is exactly the gap that lets a former employee or ex-agency keep posting. Steps 4 to 7 are the ones that actually close it.

Evaluate every Spikerz access decision across four separate layers:

A user should only have access when all four layers agree with your approved access policy.

Connect → Assign → Clean → Match → Protect → Automate → Test

This is the standard process for initial onboarding and for every social account added afterward.