## Revisions
Once published, a revision becomes locked and can no longer be changed.
To undo changes and revert to a previous state, use the **Revision** dropdown to select the version you want to revert to, then click **Revert**. You can review the changes that will be applied before submitting.
## Merge Conflicts
Your draft can diverge from the live version of a feature if someone else publishes changes while you're still editing. GrowthBook can merge some changes automatically (e.g., if you change a rule in "dev" and someone else changes a rule in "production"). For changes that can't be resolved automatically, you must fix the conflicts before publishing your draft.
The conflict resolution process works similarly to version control systems like Git. For each conflict, GrowthBook shows a diff and lets you choose how to proceed.
In the example below, the Default Value was set to `foo` when you first created your draft. In your draft, you changed the value to `bar`. At the same time, someone else published a new version, changing the value to `hi!!`. So, now you have to choose which change you want to keep.
## Approval Flows
### Environment-scoped approvals
Approvals are environment-aware. An approval only counts for the environments the reviewer can review: if a reviewer's role (or team) limits their Review permission to specific environments, their approval covers only those environments, and a draft cannot publish until its approvals together cover every environment the draft changes.
To set up a separate approver group per environment — for example, one group that signs off on `production` changes and a different group for `staging`:
1. Create a team per environment ([Settings → Members → Teams](/account/user-permissions#teams)) and give each team a role with the **Review** permission limited to its environment.
2. Add the reviewers to their environment's team.
3. Optionally add both teams to **Required approver teams** on the approval rule. Because each team can only review its own environment, a `staging` draft can then only be satisfied by the staging team, and a `production` draft only by the production team.
Even without required approver teams, environment limits alone keep the groups distinct: a reviewer limited to `staging` can never sanction a `production` change.
### Requesting a Review
When Approval Flows are enabled, you must request a review before publishing changes. Add a detailed comment describing the changes so reviewers can understand the intent of your request.
Requested reviews appear in the **Drafts** tab on the Features overview page with a **Pending Review** status. Sort by date updated to see your most recent request at the top.
### Reviewing
A reviewer needs the **Review** permission for Feature Flags, covering the
environments the draft changes (see
[Environment-scoped approvals](#environment-scoped-approvals)). The person who
created the draft cannot approve it. If **Block contributors from
self-approving** is enabled, anyone who contributed to the draft is also
prevented from approving it. See [Permissions](/account/user-permissions) for
details.
Click the feature, then click **Review and Approve** to open the review modal.
From here, you can see the diff between the currently published changes as well as the comments.
Click **Next** to write your review in the comment box and select a status:
* **Comment** — Add a note without formally reviewing the changes
* **Request Changes** — Flag issues that need to be addressed before approval
* **Approve** — Confirm that everything looks correct
Once the changes are **Approved**, they can be published.
### Publishing with Approvals
After approval, anyone with **Publish** access to the affected environments can
publish the draft. If the approval rule lists **Required approver teams**, the
draft additionally cannot publish until a member of one of those teams has
approved it. A user with **Bypass draft approvals** can publish without an
approval.
Once published, a green "Live" badge confirms the version is published and active.
### Visualize Changes with Compare Revisions
Get a detailed diff of the changes between published and draft versions by clicking the **Compare Revisions** button.
## Saved Groups
Saved groups follow the same draft → review → publish lifecycle as feature flags. Every change you make to a saved group — editing values or conditions, updating metadata, or archiving it — is tracked as a revision so you can review, compare, and roll back changes over time.
### Saved Group Revisions
When you edit a saved group, GrowthBook creates a draft revision. Drafts are visible to everyone with access to the saved group, but they don't affect SDK evaluations until they're published — so you can stage and review your changes before they reach your users.
From the saved group detail page you can:
* **Switch revisions** — Use the revision dropdown to view the live revision or any open draft. The dropdown shows the author, last update date, and review status for each revision.
* **Create a new draft** — Click **New Draft** from the live revision to start a new set of changes.
* **Compare revisions** — Click **Compare revisions** to see a side-by-side diff of any two revisions.
* **Revert to a previous revision** — Open an older merged revision and click **Revert to Previous** to apply its state as a new draft.
* **Discard a draft** — Authors can discard their own draft if they no longer want to publish it.
* **Fix merge conflicts** — If another user publishes changes while your draft is open, click **Fix conflicts** to resolve them before publishing. The conflict resolution flow works the same way it does for features.
### Saved Group Approval Flows