Config history and version restore

Config History shows every change made to your store’s configuration, who made it, when, and exactly what changed. If a change caused unexpected behavior, you can restore any previous version to roll it back.

​

Prerequisites

• Your store must be connected to Layers.
• You need dashboard access with permission to view store settings.

​

Open Config History

1. In the Layers dashboard, go to Settings.
2. Select Config History (under the Access & Security category, or search for “history” in the sidebar).

The Config History page shows a chronological table of every configuration change, newest first.

​

What is tracked

Config History covers these item types:

• Merchandising rules (including pin positions and expressions)
• Ranking rules (including promote, demote, pin, and sort actions)
• Request transforms (including targeting conditions and request modifications)
• Sort orders (including priority rules and soft-boost expressions)

Each entry records:

• Time — When the change happened.
• Type — Which item type was affected.
• Item — The name of the specific rule or sort order.
• Event — Whether the item was created, updated, deleted, or restored.
• Changed fields — Which fields were modified (for updates).
• By — The team member or system actor that made the change.

​

View change details

1. Find the entry in the Config History table.
2. Click the View details icon on the row.
3. Review the before-and-after diff for each changed field.

The detail dialog shows the exact old and new values side by side, so you can see precisely what changed.

​

Restore a previous version

1. Find the entry for the item you want to roll back.
2. Click the History & restore icon on the row.
3. In the drawer that opens, browse the full version history for that item.
4. Select the version you want to restore and confirm.

Restoring a version creates a new entry in the Config History table with the event restored, so the restore itself is tracked and can be undone by restoring yet another version.

​

Troubleshooting

​

The table is empty

Config History starts recording from the point the feature was enabled. Changes made before that date are not captured.

​

A change does not show the author

Some changes triggered by background processes (such as scheduled sync jobs) may show a system actor instead of a team member email. When a merchandising rule schedule publishes or unpublishes a rule automatically, the entry includes a reason label such as Published — schedule started or Unpublished — schedule ended. The reason label lets you tell a scheduled change apart from a manual edit.

​

Next steps

• Manage API access - Create and rotate API tokens.
• Navigate settings - Find other store configuration pages.
• Lab Insights - Review trends, anomalies, and opportunities Layers detected.