Docs Guides

Operations

Everything that changes a tenant lives under one of the workbench's six areas, Operations, grouped by the outcome an operator is after rather than by which API answers it: people lifecycle (onboard, offboard, mirror access), known fixes, app deployment, and standards (contracts, app templates). This page covers the operator's-eye view of the two planned operations -- Access Parity and offboarding -- and the evidence both leave behind. For the API shapes and server-side rules, see Workflows and Operations and evidence model.

Two shapes of change

The known-fix library (MFA reset, password reset, compromised-account lockdown, license repair, mailbox archive repair) runs Diagnose → Fix → Verify: PCB reads the current state, applies one fixed remediation, and reads again to confirm it. Access Parity and offboarding run a more general Plan → Apply → Verify shape: the operator sees every item PCB considered -- including the ones it will not touch, and why -- before choosing what to apply, then PCB re-plans server-side at apply time (so a stale plan can never apply something no longer eligible) and verifies every change by re-reading it from Graph or Exchange, never by trusting the write call. Both shapes end at the same place: a recorded run with structured evidence, reachable from /activity/runs/:runId.

Mirror access (Access Parity)

/operations/access-parity gives a target user the group memberships a source user has and they lack -- additive only. A link that already names the tenant and both people compares automatically on load; otherwise the operator picks a tenant and two people and presses Compare. Comparing never changes anything: it is a read-only plan, itself recorded as a run.

Mirror access screen showing a comparison between two Contoso users, with an additive-only notice, a list of not-compared limitations, preflight checks, and a list of eligible groups to add.

The plan splits into three groups, and the reason is always visible, never just the verdict:

Eligible -- cloud, non-dynamic, non-synced, non-role-assignable Security and Microsoft 365 groups the target doesn't already have. Checked by default; the operator can deselect individual groups before applying.
Already a member -- no change needed, so it never appears in the destructive preview or the confirmation.
Not copied -- grouped by why: dynamic membership, synced from on-premises AD, role-assignable, mail-enabled security or distribution, and directory roles. The plan also states plainly what it never compares at all: SharePoint direct site/file permissions, app role assignments granted directly to the user, Exchange mailbox/calendar permissions, and Teams-only private/shared channel membership.

Applying shows a confirmation naming the exact groups about to be added, then re-plans and applies server-side, and re-reads the target's memberships afterward to verify. Comparing needs the tenant's Viewer role; applying needs Operator.

Offboarding

/operations/offboard starts from the tenant's contract offboarding policy: block sign-in, revoke sessions, remove licenses, remove group memberships, and (optionally) convert the mailbox to shared, all pre-checked or unchecked the way the contract's policy defaults them. An operator can still adjust any of them for one leaver without touching the contract. Preview plan shows the ordered list of steps before anything runs.

Offboard screen for Priya Shah in Contoso Ltd, showing the contract policy defaults as checked actions and an ordered plan of nine steps with a follow-up reminder note.

The plan is ordered for a reason the UI states, not just enforces silently: sign-in is blocked and sessions revoked first; the mailbox is converted to shared (and forwarding set) before anything that can remove a license; group cleanup and license removal wait for a verified mailbox conversion whenever one was requested, because removing a license from an unconverted mailbox starts Microsoft's own deletion clock on it. Steps the contract's policy has no operation for yet (hiding from the address list, granting a manager full mailbox access) are listed as won't-run items with the reason, not silently dropped. Offboard user asks for confirmation naming the steps, including which are destructive, before it runs.

The evidence every run leaves

Applying Access Parity or running an offboarding both end at the same evidence view -- the same one reachable later from Activity, the person's History tab, or a direct link to /activity/runs/:runId. Wording follows the recorded outcome exactly: a change reported successful that a re-read doesn't confirm shows as Verification failed, not Succeeded, and a run where nothing changed because it was already correct shows as No change needed, not a failure.

Evidence view for a Partially succeeded Access Parity run, with a Failures panel, ticket notes ready to copy, and a breakdown of changes attempted, completed and skipped.

Every evidence view has the same shape:

Outcome -- Succeeded, Partially succeeded, Failed, No change needed, Verification failed, or Planned (a plan-only run, never applied).
Who/what/where -- operator, tenant, target, start and completion time.
Failures and warnings -- called out above the fold, not buried in the changes list.
Ticket notes -- a server-generated narrative with one Copy ticket notes button, plus Download Markdown and Download JSON for the full record.
Changes, verification, preflight and plan -- each attempted change with its result (done, failed, already in place, skipped), each post-change check PCB re-read to confirm it, the findings from before anything changed, and the full plan including items PCB never touched.

Permissions

Both planned operations follow the same per-tenant roles as the rest of the workbench (see Authentication): Viewer can plan/preview, Operator can apply, and only a tenant Owner can change who has access to it. A contract's offboarding policy itself needs the instance catalog manager role to edit -- see the offboarding policy editor on the Contracts screen under Workflows: planned operations.