🚀 This Month’s Spotlight - 3 Revisions Features You Should Start Using Today - October 2025

[Tal_Ben_Bassat]

🎯 October Spotlight: 3 Revisions Features You Should Start Using Today

Hi Check Mates 👋

This month’s spotlight is all about Revisions - your built-in time machine for Check Point Security Management.
Whether you need to roll back to a known state, reinstall a previous policy, or automatically clean up old sessions, these features will help you stay safe, organized, and in full control of your management history.

Let’s dive into this month’s top 3 features 👇

Revert to Revision

What it is

Every time you publish a session, SmartConsole automatically creates a revision - a snapshot of your management database at that moment.
With Revert to Revision, you can instantly restore your Management Server to any previous published state, returning the system to a stable configuration.

This action replaces your current database with the selected revision, effectively rolling back your management environment to a known-good version.

🚀 Use cases

• Undo unwanted configuration changes after a policy install or object modification.
• Quickly recover from an error introduced in a recent session.
• Restore a stable configuration after troubleshooting or testing.

💛 Why you’ll love it

• A single-click rollback that protects your entire management database.
• Quickly recover from configuration errors or experimental changes.
• Make updates with full confidence, knowing you can always restore a previous state.

Learn more: Database Revisions Guide

           

Install from Revision – Policy Installation History

What it is

Instead of reverting your entire management database, Install from Revision lets you deploy a previous policy version to a specific gateway or cluster - without overwriting your current configuration.

You can access this feature directly from SmartConsole → Security Policies → Installation History.
From there, you can:

1. View all previous policy installations.
2. Select any historical version of the policy package.
3. Click “Install Policy” to reinstall that exact version on the desired gateway or cluster.

This approach allows you to roll back a single gateway to a known-good policy while keeping the rest of your environment unchanged.

💡 Did you know?
You can open the Revisions view (Manage & Settings → Sessions → Revisions) to explore older sessions, compare any two revisions - even if they’re not consecutive - and generate a detailed Change Reportshowing exactly what changed.

🚀 Use cases

• Roll back a specific gateway to a previous policy version using Installation History.
• Troubleshoot issues by reinstalling a verified configuration.
• Compare installed policy versions to understand what changed between installations - rule, object, or user changes.
• Review historical policy installation for auditing, compliance checks, or rollback validations.

💛 Why you’ll love it

• Granular rollback control - reinstall an exact policy version on specific gateways or clusters.
• Built-in reliability - restore a known-good policy without reverting the entire management database.
• Clear visibility - easily track which policy was installed, when, and by whom.
• Faster recovery - get back to a stable configuration in just a few clicks.

Learn more: Policy Installation History

Purge & Automatic Purge

What it is

Revisions are invaluable, but over time they can accumulate and consume disk space.
The Purge and Automatic Purge features help you manage revision retention efficiently - manually or automatically.

You can delete older revisions from SmartConsole or configure Automatic Purge through the Management API:
set automatic-purge → API Reference 

🚀 Use cases

• Retain only recent revisions - keep your environment lean by limiting storage to a specific number or time range.
• Optimize performance - reduce disk usage and improve management responsiveness by automatically removing outdated revisions.
•  Stay compliant effortlessly - use automatic purge to enforce retention policies and ensure consistent cleanup without manual effort.

💛 Why you’ll love it

• Set it and forget it - no manual cleanup needed.
• Improves performance and reduces storage consumption.
• Keeps your revision history lean and relevant.

Learn more: Automatic Revisions Purge (SK170059)

💬 Have ideas for future Spotlights or want to share your experience?
Send us your thoughts at QuantumMgmt‑Feedback@checkpoint.com - we’d love to hear from you!

Missed our previous Spotlights? Catch up here:

• This Month’s Spotlight – 3 Features You Should Start Using Today – July 2025
• This Month’s Spotlight – 4 Features You Should Start Using Today – August 2025
• This Month’s Spotlight – 3 Features You Should Start Using Today – September 2025

[Alex-]

A strong warning in the console about the use of this feature when using VSX  would be nice.

[Tomer_Noy]

Indeed, "revert to revision" is not supported with VSX gateways (mainly because some of the VSX configuration is applied immediately to the gateway and it's not possible to revert it from the Management).

If you have VSX objects in your management / domain, the "revert to revision" feature will provide a clear message and will not allow you to proceed.

[PhoneBoy]

Funny enough, when I featured this article on the most recent CheckMates Go episode, I mentioned the limitation about VSX. 🙂

[the_rock]

I remember that, listened to it last night 🙂

[the_rock]

Excellent @Tal_Ben_Bassat 

[Daniel_Kuhl1]

Revert to revision saved me so often during developing several Python/Ansible automation stuff. Quickly going back to the initial state is so helpful in a lab and even more useful in production environments.

[the_rock]

Super helpful!

[Duane_Toler]

Aye, indeed!

For that reason, I use a "discard: true" (or false) flag in my Ansible playbooks to allow me to discard (or not) everything at the end of the playbook run. I collect and save before/after info for all of the objects being modified during the entire operation, then discard at the end.  This lets me view everything, just like the Change Report does now, but before publishing.  When I'm happy with the result, then I re-run it and publish at the end, along with optional policy install.

This seems to work well for most operations.  Of course, certain things can't work with this, like MDS Global domains needing re-assignment before working with a child domain, but it works overall.

[the_rock]

Cant wait for more videos, amazing series!