> ## Documentation Index
> Fetch the complete documentation index at: https://docs.contraforce.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Change requests

> Review, approve, and merge detection content changes in a protected repository.

In a repository with [protection](/guides/content-management-center/repositories#protection)
enabled, changes do not take effect when you make them. They collect as work in progress,
get grouped into a change request, and require approval before merging.

This gives detection content the same review discipline as code, and gives you an evidence
trail when someone asks who approved a change and on what basis.

## The flow

```
edit ──> work in progress ──> change request ──> review ──> merge
                                    │              │
                                    │              └──> changes requested ──┐
                                    │                                       │
                                    └───────────────────────────────────────┘
```

<Steps>
  <Step title="Make a change">
    Import, author, edit, or reconcile a rule. In a protected repository the result lands
    in **Work in progress** rather than changing the rule.
  </Step>

  <Step title="Group into a change request">
    From **Work in progress**, add one or more items to a new or existing change request.
    Give it a title and description.
  </Step>

  <Step title="Submit for review">
    Submitting moves it from **Draft** to **Open** and makes it visible to approvers.
  </Step>

  <Step title="Review">
    Approvers read the diff, comment, then **approve** or **request changes**.
  </Step>

  <Step title="Merge">
    Once it has enough approvals, merging commits every item to the repository.
  </Step>
</Steps>

## Work in progress

The **Work in progress** tab holds edits that have not yet been proposed. Each item records
the rule, the kind of change (**added**, **modified**, or **removed**), and its current
revision.

An item is editable while it is work in progress: open it, keep refining, and it stays out
of everyone's way until you add it to a change request. **Discard** it if you change your
mind and nothing about the baseline has changed.

Items show as **Unassigned** until they belong to a change request. Select several and
**Add to change request** to bundle them, which is the usual shape: one request carrying a
set of related edits rather than one per rule.

<Frame>
  <img src="https://mintcdn.com/contraforce/HQrSzge5Tt9yuYjk/images/content-management-center/work-in-progress.png?fit=max&auto=format&n=HQrSzge5Tt9yuYjk&q=85&s=3e81e3906ad8c40d81b10ec14d7a49db" alt="Work in progress tab with two modified rules selected, showing Add to change request and Discard actions" width="1598" height="514" data-path="images/content-management-center/work-in-progress.png" />
</Frame>

## Change request states

| State                 | Meaning                                                                |
| --------------------- | ---------------------------------------------------------------------- |
| **Draft**             | Being assembled. Not yet visible for review.                           |
| **Open**              | Submitted and awaiting review.                                         |
| **Changes requested** | A reviewer wants revisions before approving.                           |
| **Approved**          | Has the approvals it needs and can be merged.                          |
| **Merging**           | Merge in progress.                                                     |
| **Merged**            | Committed to the repository.                                           |
| **Closed**            | Abandoned without merging.                                             |
| **Conflicted**        | The repository moved underneath it and it can no longer merge cleanly. |

<Note>
  **Conflicted** usually means another change request touching the same rule merged first.
  Resolve it by revising the affected items against the current state of the rule.
</Note>

## Reviewing

A change request shows:

* **Changes** — a field-level diff for every item, old value beside new, plus the rule query
* **Review summary** — the approval count against the requirement, the author, and a box for an optional review note
* **Audit evidence** — the sequence of what happened: revisions added, work items attached, submissions for review, each stamped with who and when
* **Conversation** — comments, including comments anchored to a specific item or revision

A **Merge requirements** banner states plainly whether the request can merge yet, so a
reviewer is never left guessing why the merge action is unavailable.

<Frame>
  <img src="https://mintcdn.com/contraforce/HQrSzge5Tt9yuYjk/images/content-management-center/change-request-review.png?fit=max&auto=format&n=HQrSzge5Tt9yuYjk&q=85&s=20222513f5a341ee6c86a09e1f4569ca" alt="An open change request showing a merge requirements banner, field-level diffs for a modified rule, a review summary with approvals 0 of 1, and an audit evidence panel" width="1599" height="810" data-path="images/content-management-center/change-request-review.png" />
</Frame>

A reviewer can **approve** or **request changes**, each with a comment. Requesting changes
moves the request to **Changes requested** and blocks the merge until it is revised.
**Edit change** on an item lets a reviewer revise it in place rather than sending it back.

### Who can approve

Approvers are configured per repository under protection settings. Two constraints apply:

* The change request needs at least the **required approval count**.
* The author may only approve their own request if **allow author approval** is enabled,
  which it is not by default.

<Warning>
  If your change request is stuck in **Open** with nobody able to approve it, check the
  repository's approver list. A repository with required approvals set higher than the number
  of configured approvers cannot merge anything.
</Warning>

## External change references

A change request can carry an **external CAB reference** for organizations that track
detection changes in a separate change-management system. Record the ticket identifier
there and the two records stay tied together.

## Merging

Merging applies every item in the request to the repository, committing each as a new
version of its rule. From that point the changes behave like any other committed content:
they can be deployed, rolled back, and compared.

Merging changes the repository, not your workspaces. Deploy afterwards to push the merged
content out. See [Deploy](/guides/content-management-center/rules#deploy).

## Reviewing across repositories

The Content Management Center's top-level **Change requests** tab lists open requests across
every repository you can see, so reviewers do not have to visit each repository to find
what is waiting on them.