CMS Compliance: Sample Flows

This article presents possible use cases and corresponding sample flows that you can support. It provides a useful starting point as you plan your implementation.

Review CMS content changes for compliance

When a user changes content, you can review the change before deciding whether it should stand. The review request gives you both the live version and the proposed version, so you can see exactly what is changing.

To review a content change:

1. Subscribe to the Review Requested webhook.
2. When a user submits a publishing or unpublishing workflow, the CMS host calls Request Review, and you receive a Review Requested event.
3. Read the action to see what the user did.
4. Compare currentDataItem, the live version, with proposedDataItem, the version submitted for approval. For PUBLISH_DRAFT, only proposedDataItem is present. For UNPUBLISH_PUBLISHED, only currentDataItem is present.
5. For UNPUBLISH_CHANGED, read versionOnUnpublish when present to determine whether the user requested to preserve the latest draft edits or the live published version.
6. Apply your review decision in your own system, using submittedByUserId and submittedAt to record who submitted the change and when.

Review a batch of CMS content changes in one call

When a user submits several items from the same collection at once, the whole selection arrives as one event instead of one event per item. This keeps a multi-item submission together, so you can review it as the single unit of work the user intended.

To review a batch of content changes:

1. Subscribe to the Bulk Review Requested webhook. Subscribing to Review Requested doesn't deliver batches.
2. When a user submits a selection of items, the CMS host calls Bulk Request Review with the shared collectionId and one entry per item, and you receive a single Bulk Review Requested event.
3. Read bulkComplianceReviewRequest.complianceReviewRequests to get every review request in the batch, in the order the items were submitted.
4. Iterate over the list and read each request's action, because a single batch can combine actions. Compare currentDataItem and proposedDataItem per request exactly as you would for a single review.
5. Apply your review decision in your own system. Because the call is all-or-nothing, receiving the event means every item in the batch was fetched successfully, so you never need to reconcile a partially delivered batch.

Approve a content change and publish it

Once a reviewer accepts a change, the content still has to go live. Approving a review request applies the action the user originally requested, so you don't have to work out which CMS call each item needs.

To approve a content change and publish it:

1. Receive a Review Requested or Bulk Review Requested event and present the change to your reviewer.
2. Collect the compliance review requests the reviewer accepted. Group them by collection, because a single call settles items from one collection.
3. For each UNPUBLISH_CHANGED request, set versionOnUnpublish to KEEP_LATEST_DRAFT_VERSION or KEEP_LIVE_PUBLISHED_VERSION, depending on which version the reviewer wants preserved as the saved draft.
4. Call Bulk Approve Request Review with the collection's published ID as prodCollectionId and the accepted requests as items. Each item's action is applied: publish items go live, and unpublish items are retracted.
5. Read publishResult and unpublishResult to confirm the content change for each item, matching entries to your request through itemMetadata.originalIndex.
6. Read statusUpdateResults to confirm each item's requestReviewStatus is now APPROVED. Read it here rather than from the returned review requests, whose data items are read before the status is written. Don't treat the status as proof the content changed: a PUBLISH_* item's status is set before it's published, so it can be APPROVED with its publish still having failed. Retry any item that publishResult or unpublishResult reports as failed.

Reject a content change

When a reviewer turns a change down, the content must stay as it is while the decision is still recorded. Rejecting a review request writes the decision to the data item without touching its content.

To reject a content change:

1. Receive a Review Requested or Bulk Review Requested event and present the change to your reviewer.
2. Collect the compliance review requests the reviewer turned down, grouped by collection.
3. Call Bulk Reject Request Review with the collection's published ID as prodCollectionId and the rejected requests as items. Nothing is published or unpublished, so each item's content is left exactly as it was.
4. Read statusUpdateResults to confirm each item's requestReviewStatus is now REJECTED, matching entries to your request through itemMetadata.originalIndex. As with approving, read the status here rather than from the returned review requests.
5. Subscribe to the Bulk Review Rejected webhook to notify your other systems of the decision. The event fires once per call and carries the same results the call returns.

Forward content changes to an external compliance system

If you maintain an external audit or compliance system, you can keep it in sync with every reviewable content change on the site.

To forward content changes to an external system:

1. Subscribe to the Review Requested and Bulk Review Requested webhooks, so that both single submissions and batches reach your system.
2. On each event, extract the complianceReviewRequest object, or for a batch, each object in bulkComplianceReviewRequest.complianceReviewRequests. Include the action, currentDataItem, proposedDataItem, optional versionOnUnpublish, and submittedByUserId.
3. Transform the data into your external system's format.
4. Send the transformed records to your external system.