Partner Center BridgeDocs

Docs Guides

The workflow library

Known-fix workflows are the tickets your queue sees every week, encoded once, done right every time. Each one runs Diagnose → Fix → Verify: the diagnosis is shown verbatim before anything changes, the fix is applied step by step, and a fresh diagnosis proves (or disproves) the result. Every run is recorded with the operator's identity.

Identity

MFA / auth method reset mfa-reset

The "lost phone" ticket. Diagnose lists the user's registered authentication methods and warns when no strong method exists. Remediate revokes all sign-in sessions and removes every deletable registered method, forcing clean MFA re-registration at next sign-in. The password method is never touched.

Password reset + session revoke password-reset

Sets a generated 16-character temporary password (must change at next sign-in) and revokes existing sessions so the old credential stops working everywhere. Diagnose flags directory-synced accounts as a Blocker - a cloud-side reset doesn't stick for those; reset on-premises or via SSPR writeback instead. The temporary password is shown to the operator exactly once and never lands in run history or notifications.

Compromised account lockdown compromised-lockdown

First-response containment for a suspected BEC. Diagnose shows sign-in state, MFA registration, and inbox rules that forward, redirect, or delete mail - the classic persistence trick. Remediate blocks sign-in, revokes every session, and disables the risky rules (disabled, not deleted, so they survive as evidence for the investigation).

License assignment repair license-repair

The license that "is assigned but doesn't work". Diagnose checks the usage location (the usual silent culprit) and finds stuck SKUs. Remediate sets the usage location and reprocesses the assignment.

Mailbox

Mailbox archive repair mailbox-archive

The "mailbox full / not archiving" fix that replaces a ~10-cmdlet Exchange Online dance. Diagnose shows the full archive posture: sizes against quotas, archive + auto-expand state, retention policy, and the two hidden blockers (retention hold, disabled ELC processing) that silently stop the Managed Folder Assistant. Remediate enables the archive and auto-expansion, ensures a retention policy, clears the blockers, and kicks the assistant. The actual item move runs asynchronously on Microsoft's side - re-running remediate doubles as the nudge, which this problem routinely needs.

Planned operations: Access Parity and offboarding v2

Alongside the known-fix workflows above, two operations follow a formalized Plan → Apply → Verify shape (IPlannedOperation): the operator reviews an explicit plan -- every item considered, including ones PCB will not touch and why -- before choosing what to apply, and every apply re-plans server-side and verifies by re-reading the result, never by trusting the write call. See Operations and evidence model for how this fits alongside the older diagnose/remediate workflows.

Access Parity access-parity

Gives a target user the cloud group memberships a source user has and they lack -- additive only: the only write it can issue is adding the target to a group, and a membership the target already has that the source lacks is never touched. Only cloud Security and Microsoft365 groups are eligible; dynamic, on-premises-synced, role-assignable, mail-enabled security, and distribution groups are all listed with the specific reason they are not copied, and directory roles are never copied. The plan always states what it does not cover: SharePoint direct (non-group) site/file permissions, app role assignments granted directly to the user, Exchange mailbox/calendar permissions (Full Access, Send As, delegate access), and Teams-only private/shared channel membership. POST /api/tenants/{tenantId}/operations/access-parity/plan (Viewer) and .../apply (Operator) take a source and target user; apply is idempotent (already-present counts as NoChangeNeeded, not a failure).

Offboarding policy v2

Contract.OffboardingPolicy makes each offboarding step optional and per-contract: block sign-in, revoke sessions, group cleanup (None/RemoveAssignable/ RemoveAll), convert the mailbox to shared (+ optional forwarding), remove licenses, retire devices, and a follow-up reminder day recorded in evidence only. The defaults reproduce the pre-policy behavior exactly. Ordering is a guarantee: sign-in is blocked and sessions revoked first; the mailbox conversion (and forwarding) runs 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 its deletion clock. hideFromGal and managerAccess are always listed as ineligible today -- PCB has no Exchange operation for either yet, and the plan says so. POST /api/provisioning/terminate/plan and .../terminate use an effective policy of request overrides > the tenant's contract policy > built-in defaults; GET/PUT /api/contracts/{id}/offboarding-policy manage the contract's policy.

Run history & notifications

The Workflows tab shows recent runs: when, which workflow, which tenant, which operator, and the outcome. The full findings and steps of every run persist in the database (SQLite in the Windows program, Postgres on a server) - ticket-ready evidence of what was checked and what was changed; planned operations additionally carry structured OperationEvidence (preflight, plan, changes, verification, warnings, limitations, a ticketNotes narrative, and a strict outcome), retrievable as JSON or as a Markdown ticket note via GET /api/workflows/runs/{runId}/evidence?format=markdown. Configure the Notifications section to push failed runs to a Teams incoming webhook (Adaptive Card) or any JSON receiver: 

"Notifications": {
  "WebhookUrl": "https://...",   // empty disables
  "Format": "teams",             // or "json"
  "NotifyOnSuccess": false
}

Writing your own

Implement IWorkflow in the project that owns the API you're calling, register it in that project's Add*Workflows() extension, and it appears in the catalog, the UI, and run history automatically. Guidelines:

  • Diagnose must be read-only and explain why (Warning findings carry the reason, not just the fact).
  • Make remediation idempotent where possible and explain repeat effects. A password reset or session revocation can affect the user again; a rerun is not automatically harmless.
  • Use WorkflowRunResult.Ephemeral for show-once secrets - it is excluded from persistence and notifications by construction.
  • Cover it with WireMock tests; no live tenant needed.

See CONTRIBUTING.md for the full conventions.