Kav
עברית Try the assistant
Menu
Kav Desk for Dynamics

Maintaining a live Dynamics surface: origins, scopes, and erasure

Day-two operations for an already-onboarded Dynamics panel: managing origins, linking staff identities, scoping access, and the erasure ledger.

By The Kav team Published 2 min read

Onboarding a Dynamics surface (see the separate 13-step wizard guide) is a one-time act. Everything on this page is what you come back to afterward — the surface's own detail screen, reached from the Bridge module's list.

The three-act lifecycle

A surface is always in exactly one of three states, and each move between them is its own separately permissioned act:

  • Activate (bridge.surface.activate) — moves a surface from Mock to Live, or a Paused one back to Live. Requires pinning the solution version.
  • Pause (bridge.surface.pause) — moves Live to Paused. This is deliberately the safe direction: it requires a typed reason, but no elevated permission beyond the pause grant itself.
  • Resume — the same activate permission as going live the first time, because resuming a paused surface is exactly as consequential as activating a new one.

A paused surface shows its own pause reason on its detail screen — check it before resuming. A surface paused for "vendor role mapping was wrong" needs that fixed first, not just a click to resume.

Managing origins

The list of web origins allowed to embed this panel. An origin isn't optional bookkeeping — Surface.Activate refuses a surface with zero allowed origins outright, so add at least one before you ever try to go live, and add a new one here the moment the customer stands up a second Dynamics environment or a new deployment URL.

Most staff reach the panel through the JIT (just-in-time) groups configured at onboarding — no separate action needed per person. Identity links are the manual override: linking one specific Entra directory subject to one specific Kav staff member id, for the case where automatic group provisioning isn't the right fit for someone. Unlinking requires a typed reason, the same discipline as pausing a surface.

Principal scopes

The same grant mechanism from onboarding's step 11, available here for ongoing changes: a predicate (can open the panel, can be impersonated, can own created records, can run setup) granted to a directory group, a vendor role, or a vendor team. Add a grant here any time the rollout's access needs to widen — there's no separate "edit" for a grant, only adding new ones.

The erasure ledger

Every mapped record moves through a fixed sequence: Mapped → DeleteRequested → RowDeleted → HistoryDeleted → RetentionAttested. Requesting erasure for a record is the operator action available here; the remaining transitions happen as the underlying deletion and retention-policy attestation actually complete. A record sitting at HistoryDeleted still needs someone to attest that retention requirements are satisfied before the ledger considers it closed.

The ledger is the audit trail for "did we actually delete this when asked" — read it as a compliance record, not a queue to clear quickly. A record that never advances past DeleteRequested is a real problem worth chasing, not a UI glitch.