> For the complete documentation index, see [llms.txt](https://user.netmera.com/netmera-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://user.netmera.com/netmera-user-guide/web-tools/web-personalization/security-review.md).

# Security review

Security review is an optional approval step that sits between finishing a personalization and launching it. Instead of changes going live the moment they are launched, they are packaged into a version and an authorized reviewer decides whether that version reaches the site.

{% hint style="info" %}
Security review is optional and disabled by default. To enable it for an app, contact your Netmera account manager. While it is disabled, Launch behaves exactly as documented elsewhere in this guide and none of the elements below appear in the panel.
{% endhint %}

### Why use it

A personalization launch injects changes into the live site. Organizations with strict change-control or information-security policies usually require an explicit approval before that happens.

With security review enabled:

* No personalization reaches the site without an explicit approval.
* Every published version carries a named approver.
* Every version keeps a full record of who created it, who requested review, and who approved or rejected it.
* The approval cannot be bypassed: the launch endpoint called directly is rejected while the flow is enabled.

### Roles

| Role                                                                        | What it can do                                                                                                                                 |
| --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| <p><strong>Creator</strong><br>Any user with Web Personalization access</p> | Creates personalization experiences and sends them to review. Cannot publish directly — Approve, Reject, and Download Version are not visible. |
| <p><strong>Security Reviewer</strong><br>Approver</p>                       | Everything a Creator can do, plus approving or rejecting the version waiting for review, and downloading the version file.                     |

{% hint style="warning" %}
Web Personalization reuses the **Security Reviewer** role defined for [Tag Manager security review](/netmera-user-guide/web-tools/tag-manager/security-review.md) — no separate role is needed. Assign it to at least one panel user before security review is enabled, or versions sent to review cannot be approved and publishing stops.
{% endhint %}

### Send changes to review

{% stepper %}
{% step %}

#### 1) Build the experience

Create or edit a personalization experience as usual. Preview behaves exactly as before.
{% endstep %}

{% step %}

#### 2) Click Send to Review

On the **Go** step, the **Launch** button appears as **Send to Review** when security review is enabled.
{% endstep %}

{% step %}

#### 3) Add a version note

A dialog opens for the version note. Describe what changed and why — this is the note the reviewer reads, and it is included in the notification email.
{% endstep %}

{% step %}

#### 4) Confirm

All personalizations due to go live are snapshotted together as one container version. The container moves to **Waiting Review** and locks, and the panel opens **Version History**. All Security Reviewers receive an email.
{% endstep %}
{% endstepper %}

### One review queue at a time

Only one container can wait for review at a time. If a container is already in review, a new **Send to Review** does not open a second version — the change is added to the version already in review, and Security Reviewers are notified again.

This has two consequences worth planning around when several people work in parallel:

* Version notes are cumulative. Notes submitted by different users appear as separate, dated lines on the version detail page.
* Approval and rejection apply to the whole container. Rejecting one person's change rejects the entire package.

**Review Requested by** and its date always reflect the most recently submitted personalization.

### Review a version

A Security Reviewer opens the version detail page — or **Review Actions** in the Version History table — to see the changes included in the container (selector, change type, description) and the JavaScript output that will be produced.

* **Approve** — a publish note is entered, the standard publish flow runs, and the version becomes **Live**. The previous live version moves to **Past**. If the publish fails, the version stays in **Waiting Review**, so there is no partly published state.
* **Reject** — a reject note can be entered, and the container becomes **Rejected**. Its personalizations return to draft, where they can be edited and sent to review again — by any user with access, not only the original creator.

### Version History

A **Version History** table on the Web Personalization dashboard lists every container version.

| Status             | Meaning                                                 | Available actions                       |
| ------------------ | ------------------------------------------------------- | --------------------------------------- |
| **Waiting Review** | Submitted and waiting for a Security Reviewer decision. | Review Actions (Security Reviewer only) |
| **Live**           | Approved and published to the site.                     | Stop                                    |
| **Rejected**       | Reviewed and declined.                                  | Archive, delete                         |
| **Past**           | Previously live, replaced by a newer approved version.  | Archive, delete                         |

### Experience statuses on the workspace

The workspace table reflects where each personalization stands in the flow:

* **In review** — submitted and waiting for a decision. No actions are available.
* **Published** — approved and live. Copy and stop actions are available.
* **Draft** — rejected, or not yet submitted. Edit, delete, and archive actions are available, and the record can be sent to review again.

### Audit trail

The version detail page records the full decision history:

* **Created by** and date
* **Review Requested by** and date
* Cumulative **Version Note** lines, each with its own date
* **Approved by** and date, with the **Publish Note** — or **Rejected by** and date, with the **Reject Note**

Approved and Rejected fields appear only once a decision has been made.

### Notifications

| Event                                      | Who is notified           | What the email contains                                          |
| ------------------------------------------ | ------------------------- | ---------------------------------------------------------------- |
| Version sent to review                     | All Security Reviewers    | Link to the version detail page and the cumulative version notes |
| A change is added to the version in review | All Security Reviewers    | Link to the version detail page and the cumulative version notes |
| Version approved                           | The user who submitted it | Link to the version detail page and the publish note             |
| Version rejected                           | The user who submitted it | Link to the version detail page and the reject note              |

### Download Version

Security Reviewers see a **Download Version** button on the version detail page and can download the version file for offline inspection or archiving. The button is not visible to other roles, or when security review is disabled.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://user.netmera.com/netmera-user-guide/web-tools/web-personalization/security-review.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.