Fleet management is live: Workspace Profiles and onboarding at scale

Reviewed by ContraForce Security Operations Team · Updated 2026-08-12

Your on-call rotation changes. The distribution list that should receive incident notifications is a different one starting Monday. In one workspace that is a single edit. Across two hundred customer workspaces it is two hundred edits, and every one of them is the same edit.

The clicking is not the real cost. The real cost is that nobody finishes. The change lands on part of the book, someone gets pulled into a live incident, and the rest stay on last quarter's standard. After that, every question about your delivery standard turns into an audit.

Fleet-wide configuration is uncomfortable for a good reason. The blast radius is the whole book, and most tools ask you to trust a button. Fleet management in ContraForce is built on the opposite premise: you should be able to read a change, workspace by workspace, before you make it.

A Workspace Profile is a template, not a switch

A Workspace Profile is a reusable template. Configure it once, attach the workspaces it should manage, and apply it. One edit and one apply pushes configuration to many workspaces. It is built for partners running more than a handful of customer workspaces. A profile has five sections:

• IAM: user and group access, with role assignments.
• Modules: which detection and response modules are turned on.
• Notifications: incident, Gamebook, and agent run notification preferences, and who receives them.
• Gamebooks: the approvers who authorize manual response.
• Agent: Security Delivery Agent policy, and optional auto-provisioning.

Every section is optional, and an empty section leaves the workspace's existing settings alone, so a profile that only sets notifications will not reset anyone's module list. One restriction to plan around: notification recipients must be your own people, with an identity that exists across workspaces, not individuals inside a customer tenant. You name the profile, configure the sections in separate tabs, and it all saves as a single version.

Attaching is not applying

This is the separation that makes the rest of it safe. Attaching, which is choosing the workspaces a profile manages, is a separate step from applying, and it does not configure anything on its own. You can build the standard, attach the workspaces it should govern, and walk away without having changed anything in a customer environment.

What does the apply preview actually show you?

Before anything deploys, the preview shows you, workspace by workspace, exactly what will be added, updated, or removed. Not a count. The changes themselves, attributed to the workspace that will receive them. You read them before you commit, not afterward in a support thread.

One case gets special handling. If the profile's modules would change a workspace's plan and add a recurring charge, the preview flags that workspace and requires acknowledgment before proceeding. Without it, the Modules section is skipped and the rest of the profile still applies. Nobody gets a surprise line item because a profile was attached to one workspace too many.

Applying the same profile twice is safe. ContraForce brings each workspace towards the profile rather than duplicating what is already there. If you are not certain an apply finished, run it again.

What happens when a workspace falls behind

Profiles carry version numbers, and each profile shows its own sync status. All in sync means the attached workspaces match the current version. Waiting to be applied means the profile has advanced past them. When only part of the fleet is current, the status names it directly: N of M workspaces not yet on that version. Editing the profile's name or description does not create a new version, so housekeeping never makes a fleet look stale.

The Activity tab records each apply run with the version pushed, the actor who pushed it, and the outcome for every workspace in the run. Run statuses are Queued, Running, Applied, Partially applied, Skipped, Failed, and Provisioning. When a customer asks who changed their notification recipients, that is a lookup, not an investigation.

Retry is more careful than it looks. It reapplies the same version the original run pushed, not whatever the profile says now, so an edit made between the failure and the retry does not ride along. It also leaves already-successful workspaces untouched. A workspace can show out of sync after a partially applied run until the reason is resolved and the run is retried, which is the honest state rather than a green check.

Detaching a workspace stops the profile from managing it. It does not strip out configuration the profile already applied. Removals are deliberate, never a consequence of a workspace leaving a profile, because the alternative is an admin unchecking a box and stripping access from a live customer environment.

Sections, versioning, and run statuses are documented in Workspace Profiles.

Onboarding a book of customers

The same profile does the work at creation time. There are two paths: create a single workspace with an optional profile applied, or batch import a CSV file of up to 200 rows, one workspace per row. Both apply the profile's access, modules, notifications, and Gamebook settings as the workspace is created. That ordering is the point. The workspace is not created and then configured later by whoever picks up the ticket on Thursday. The CSV template has four columns:

• Tenant name. Required. The display name, up to 200 characters.
• Tenant ID. Required. The customer's Microsoft Entra tenant ID, as a GUID.
• Profile name. Optional. It must match an existing profile exactly.
• Admin email. Optional. Where the invite is sent.

The importer accepts comma, semicolon, and tab separated files and tolerates header variations, so tenantid and Directory ID both resolve. Maximum file size is 512 KB. The column to think hardest about is Profile name: it decides whether a workspace arrives configured or arrives blank. It is set per row, so one file can land your standard profile across most of the book and a different one on the customers who negotiated their own approval rules.

Validation runs before anything is created. It fails the bad row instead of guessing at it.

• A missing tenant name or tenant ID fails that row, and only that row.
• An invalid GUID is rejected rather than corrected.
• Duplicate tenant IDs inside one file are flagged.
• An unrecognized Microsoft Entra tenant shows a warning and still imports.
• Row numbers count the header as row 1, so the number in the error matches the line in your file.

Then rows process in order and you watch them: Queued, Running, then Succeeded or Failed with the reason shown. Succeeded workspaces land in the Onboarding tab. If an import stalls, a Resume option appears and continues without recreating workspaces that already exist. When some rows fail, do not re-upload the whole file to fix them. Build a new CSV containing only the failed rows.

The customer admin finishes the handshake through an invite link that grants ContraForce access to their tenant, and the workspace moves from the Onboarding tab to the active Workspaces tab. To confirm a profile actually landed, open it and read the Activity tab.

Column formats, validation errors, and the import walkthrough are in Onboarding workspaces at scale.

What do you need before the first apply?

The permissions are deliberately narrow, because one apply reconfigures every attached workspace.

• Only an Organizational Admin can view, create, edit, and apply profiles. Running the onboarding import needs Organizational Admin or Workspace Admin.
• A service provider account. Agent Center is optional unless you are deploying Security Delivery Agents.
• Every customer's Microsoft Entra tenant ID as a GUID. Usually the long pole, so start collecting before the contract closes.

Agent provisioning follows the same logic. With provisioning enabled, a profile can auto-create agents, but your environment must have committed an agent deployment model first, and agent deployment needs Owner rights on the subscriptions. A single apply provisions up to 50 agents. Anything beyond that is skipped with a reason and picked up by your next apply.

Start with one profile and two workspaces

Do not start by attaching your whole book. Most providers already own this standard: it lives in an onboarding checklist, or in one senior engineer's head. Build one profile that encodes a piece of it you already enforce by hand, an analyst role set or a notification recipient list, and leave the other sections empty. Attach two workspaces you already run, then read the apply preview against what you expected those workspaces to look like.

If it matches, your standard is written correctly and the CSV is the same thing at scale. If it does not, you have found the gap between the standard you think you run and the one you actually run, on two workspaces instead of two hundred. Apply, then open the Activity tab and confirm the version, the actor, and the outcome. You now have a profile you trust, and a place to put the next standard instead of hand-carrying it.

Bulk operations across workspaces are an add-on on the Starter plan and included from the Growth plan upward: compare the plans.

If you run Microsoft Sentinel and Defender XDR across more customer tenants than you can configure by hand, ContraForce gives you one place to define the standard and a preview of what applying it will do: start a trial and build your first Workspace Profile.

What is "Fleet management is live: Workspace Profiles and onboarding at scale" about?

In a per-workspace console, every configuration decision is multiplied by the size of your book. A Workspace Profile is your delivery standard written down once, and apply is the act of bringing every attached workspace to it.