Fleet management is live: Workspace Profiles and onboarding at scale

Reviewed by ContraForce team · Updated 2026-09-04

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. So fleet management in ContraForce is built to be read before it is run. You see the change, workspace by workspace, before you make it.

Your delivery standard, written down once

A Workspace Profile holds the standard in one place: who has access, which modules run, who gets paged, and which responses an agent can take without asking. The things a customer notices when they are wrong. Configure it once, attach the workspaces it should manage, and apply it. The edit you used to make two hundred times you now make once, and then you read what it is going to do.

Every part of it is optional, and the parts you leave empty do not touch the workspace, so a profile that standardizes notifications will not quietly reset anyone's module list. One thing to plan around: notification recipients have to be your own people, with an identity that exists across workspaces, not individuals inside a customer tenant. Agent provisioning is in the profile too, on the workspaces where you already hold the rights to deploy.

Attaching is not applying

This is the separation that makes the rest of it safe. Choosing which workspaces a profile manages is a separate act from applying it, and on its own it configures nothing. You can write the standard, decide where it should govern, and walk away without having changed anything in a customer environment.

Because one apply reconfigures every attached workspace, applying belongs to an Organizational Admin and nobody else. One person can move the whole book, so one role can.

What the preview shows 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 move a workspace onto a different plan and add a recurring charge, the preview stops and asks you to acknowledge it, and leaves that part alone if you do not. 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 toward the profile rather than duplicating what is already there.

When a workspace falls behind

Profiles are versioned, and each one tells you where its workspaces stand: all current, or how many are still behind. Housekeeping like renaming a profile does not count as a change, so tidying up never makes a fleet look stale.

Every apply is recorded with the version, the person who ran it, and the outcome for each workspace. 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 version the original run pushed, not whatever the profile says now, so an edit made in between does not ride along, and the workspaces that already succeeded are left alone. A workspace that only partly applied keeps saying so until you deal with it, which is the honest state rather than a green check.

Detaching a workspace stops the profile from managing it and leaves the configuration it already applied in place. Stripping access from a live customer environment should take a deliberate act, not an unchecked box.

A new book of customers, configured on arrival

The same standard does the work at creation time. Create a workspace with a profile applied, or import a CSV and create them in bulk, one workspace per row. Either way the standard is in place when the workspace appears. It is not created empty and configured later by whoever picks up the ticket on Thursday.

The column that matters most is the profile name, because it is set per row. One file can land your standard across most of the book and a different standard on the customers who negotiated their own approval rules.

Validation runs before anything is created, and it fails the bad row instead of guessing at it. When rows do fail, fix them in a new file containing only those rows rather than re-uploading everything.

One expectation to set with the customer: the workspace is not live until their admin accepts an invite granting ContraForce access to the tenant. And collect Microsoft Entra tenant IDs early. That is usually the long pole, so start before the contract closes.

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 rest empty. Attach two workspaces you already run, then read the preview against what you expected those workspaces to look like.

If it matches, your standard is written correctly and the whole book 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.

Profile settings, versioning, and apply history are documented in Workspace Profiles.

The full import walkthrough, including the column reference and the validation errors, is in Onboarding workspaces at scale.

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, start a ContraForce trial. No credit card. Build one profile, attach two workspaces, and read the preview: create an account. If it does not match what you expected those two to look like, you have your answer.

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 brings your attached workspaces to it after showing you, workspace by workspace, what it will change.