Operate Content Review

Platform operator guide for the Content Review module (/content-review) — who approves, what done looks like, and how validation blockers appear in the UI. No developer workstation or integration manifest steps on this page.

Prerequisites

• Tenant ACTIVE and document datasources syncing successfully
• Business roles and approver permissions assigned (document-record:read and approval-capable roles per your governance pack)
• Data stewards identified for each document corpus (legal, sales operations, knowledge management)
• Integrator has published document-storage configuration with required dimensions and links declared

Where it happens

• Dataplane UI — Content Review (/content-review) — pending queue, review panel, save draft, approve
• Email, Slack, or Microsoft Teams — alerts when new documents need review (when enabled for the tenant)
• Enterprise search — approvers pick foreign-key targets through governed record search (same ABAC as end users)

Integrators configure required fields and processing flags on the Configure Content Review guide after you confirm steward roles and policy.

Steps

1. Confirm approver roster — map business roles (for example Contract Steward, Sales Operations) to users who may open the approval queue.
2. Open Content Review from the main navigation — verify you see the queue or the all-caught-up empty state.
3. Triage pending items — use search and status filters; prioritize documents blocking assistant or search certification.
4. Open a document for review — read Original vs Recommended metadata; note required field labels and validation banners.
5. Resolve blockers before Approve — complete required dimensions (sensitivity, lifecycle stage, department) and required links (customer, deal, project) via the governed pickers.
6. Save draft when work is partial — stale concurrent edits surface as a conflict; refresh and retry rather than overwriting a colleague.
7. Approve only when validation clears — the Approve action stays disabled while required metadata or links fail eligibility.
8. Monitor failed sync separately — failed ingestion is not the same as Needs Review; escalate to integrator or source system owner.
9. Record accountability — note who approved high-risk corpora for audit requests (platform retains approval events).

What done looks like

Review panel behavior

Operators should expect this order in the review panel:

1. Overall confidence indicator when enrichment ran
2. Validation blockers when approval is not allowed
3. Metadata card with Original and Recommended columns for governed fields
4. Human-readable sync labels (for example Needs Review instead of internal codes)

Required fields are labeled in the UI. Read-only manifest fields cannot be edited in the panel — if a value is wrong, escalate to the integrator to fix mappings or source extraction.

Foreign-key and search empty states

When linking a document to a record (deal, customer, project), distinct empty states help triage:

Validate

• Pilot approver completes one end-to-end approval on a test document
• Approve remains disabled until required link is set when manifest marks link as required
• Non-approver user cannot access queue or foreign-key targets outside scope
• After approval, governed search returns the document for entitled users only
• Integrator sign-off on manifest matches steward expectations (documented on configure track)

Limits

Notification delivery depends on tenant configuration — email, Slack, and Microsoft Teams each require the integrator to publish a communication Connected System and the platform admin to connect channels per Connect assistant channels. Not every environment enables all channels on day one.

Bulk metadata update tools, when available, follow the same validation rules as single-document save; operators should not bypass the queue with unsupported bulk paths without integrator guidance.

Common mistakes