Web personalization 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.

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.

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

Web Personalization reuses the Security Reviewer role defined for Tag Manager security review — 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.

Send changes to review

1

1) Build the experience

Create or edit a personalization experience as usual. Preview behaves exactly as before.

2

2) Click Send to Review

On the Go step, the Launch button appears as Send to Review when security review is enabled.

3

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.

4

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.

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.