Review, conflicts & undo

The review inbox

Pending changes appear in Inbox, grouped when one agent makes the same kind of change to many documents, so a batch of 40 similar edits can be reviewed together. Each change shows:

• a field-by-field diff, including word-level changes inside rich text;
• a rendered before/after preview in a sandboxed frame (no scripts, strict content security policy);
• the risk, the rule findings, the agent and the reason it gave;
• other pending changes to the same fields, if any.

Reviewers approve or reject with an optional note. The note goes back to the agent through get_change_status, so it can avoid the same mistake. Slack alerts include a direct “Review now” link.

Owners, admins and reviewers can review. Viewers can see everything but can’t decide.

Client approval links

Agencies often need a client to sign off before a change goes live. From the inbox (select held changes and choose Send to a client) or from a change, create a link for someone without an account. Give their name, and optionally an email address (we send the link for you), a message, a deadline and how long the link works (14 days unless you choose otherwise).

• The page shows your agency’s name and logo (set them in Settings), and for each change: its title, the site, the word-level diff, the rendered before/after preview and the risk explained in plain words. The client can Approve, Request changes with a note, or Approve all.
• Approval attaches to the version shown. If the agent replaced the change, or someone edited the same content in the CMS after it was proposed, the client is told “this changed since the link was sent” and their answer isn’t applied. Approved changes go through the same conflict checks, schedules and undo as any other.
• Who decides: the client answers on behalf of the member who sent the link, so the link only works for changes that member may decide (routed changes stay with their assignees). Every answer is recorded in the audit log as Client: name (review link).
• Two-person approval: a client’s approval counts as one approval. On a change that needs two approvers, a member of the workspace gives the other one; a second link can’t.
• Deadlines in writing: a link can carry a deadline, and optionally the clause “approve low-risk changes automatically if there’s no answer by the deadline”. The client sees both on the page. Only low-risk changes that need one approval are ever approved this way.
• A link stops working when you withdraw it, when it expires, or once every change on it has been decided. Only a hash of the link is stored; the page is never indexed and doesn’t pass the link on to other sites. Links and their answers are listed on each change and under Client links.

Client approval links are part of the Agency, Business and Enterprise plans.

Review deadlines and backup reviewers

In Settings → Review deadlines, choose how many hours reviewers have to decide a held change. Each held change then shows when it is due (“due in 5 h”, “overdue”) in the inbox and on the change.

• At about three quarters of the time, the people who can decide it get one reminder by email and Slack.
• When the deadline passes, the backup reviewers you pick are asked to step in, for example while someone is on holiday. Changes routed to specific people get the backups added as assignees, so they can decide them.
• If you turn on Approve low-risk changes automatically when the deadline passes, low-risk changes that need one approval are approved at the deadline, recorded as Deadline (auto-approved) and undoable like any change. Medium and high risk changes, blocked changes and changes that need two approvers always wait for a person. Nothing is approved automatically during an emergency stop.

How approved changes are applied

An approved change is applied on top of the document’s current state, not the state when it was proposed, and Lyntcast takes a snapshot first. Only the fields the change touches are written.

Conflicts

• Version checks: agents pass the version they read as base_version. A change based on an outdated read is refused and the agent is told to re-read.
• No silent overwrites: every change records the values of the fields it touches. If another agent or a person edits those fields before approval, approving turns it into a conflict. The reviewer sees when proposed / now / this change wants and chooses Apply anyway (recorded) or Reject.
• Replaced proposals: a newer proposal touching the same fields replaces an older pending one.

Scheduled changes

Agents can pass publish_at to go live later and revert_at to end a change automatically, such as a sale or a seasonal banner. The reviewer approves the start and the end together. Scheduled runs happen every minute. If the content was edited in the meantime, a scheduled end follows the same safety rules as undo and alerts you when it can’t proceed.

Undo

• One change: if the document is unchanged since, the exact snapshot is restored. Otherwise only the fields that change touched are restored, and undo refuses (and explains why) if those fields were edited again.
• Everything one agent did: on the Activity page, undo all changes an agent made in a time window.
• Deletes: each CMS’s delete is chosen to be reversible where the CMS allows (trash, archive, unpublish); see Connect your CMS.

Document history

Each document has one timeline: proposals, approvals, applies, undos and edits seen in the CMS. For WordPress, saved revisions are listed too, with Restore this version.

Audit log

Every action is appended to a hash-chained audit log: each entry includes the hash of the one before it. The Audit page runs an integrity check, and admins can export the full log as JSON with the integrity result.