Understand a published change and review what to carry forward.

1. Choose the history that answers your question

Open Operations > Rulebase history. The Rulebase history link in Rulebase opens the same page with your selected context. A working Check Point connection and a license allowing Core Operations are required.

• Published changes: choose an instance and date interval to investigate what Management reported across that domain, including other packages and layers.
• Saved versions: choose the instance, policy type, package, and layer explicitly. Access Control, Threat Prevention, and HTTPS Inspection use a selected layer; NAT uses the package without a layer.

History requires global rules:view. A team scope or individual rule grant alone does not grant access to the archive. Global viewers can read, compare, manually capture, and keep versions. Deletion and automatic-history settings also require rules:edit. Restoring fields needs that edit permission, an eligible direct-edit or Rulebase approval workflow, and a configured write credential. See Access and permissions.

For the Linux/Security example, have a globally authorized firewall administrator capture the relevant layer before and after the agreed change. The Linux operator's delegated access and the Security reviewer's approval assignment do not themselves grant archive access.

Investigate publications when needed

Use this report when investigating a publication or an interval without saved versions. To prepare before a planned change, continue directly to saving a version below.

1. Select Published changes and the intended Instance.
2. Set From and To around the event. Use an interval of at most 31 days; dates and times are displayed in your browser's local timezone.
3. Choose Load reported changes. Review publication times, publishers, operations, and names. Use Next sessions when another page is available.
4. Open View details for a reported operation to inspect the available before and after values.

Read coverage notices before drawing a conclusion. Coverage is incomplete for this request means the report cannot establish a complete account of that interval. Not reported means Management did not supply the field; it does not prove that the field was cleared or deleted. A report with no operations is not proof that nothing changed when coverage is incomplete.

This report includes other rulebases in the selected Management domain. It cannot reconstruct a complete saved version from before your first capture. Unpublished private edits are outside this view, and a publication does not establish that policy was installed on gateways. Use Audit and evidence to investigate decisions and actions recorded by Naradox.

2. Save a complete version of the selected rulebase

1. Open Saved versions and select the exact rulebase context.
2. Read the capture description. An Access, Threat, or HTTPS capture covers only the selected layer. Referenced inline layers need their own captures; NAT covers the selected package's NAT rulebase.
3. Optionally enter a Version label, such as Before Linux cleanup CHG-1042, then choose Save current version.
4. Wait for the capture to finish and the saved-version list to refresh. Verify its label, capture time, and displayed rule count.

A queued job is still in progress. Use Check capture job, or ask an authorized operator to follow it in Platform > Jobs, when necessary. A failed capture creates no partial version. If another publication overtakes the requested capture, review the current context and capture again.

Capture reads the complete selected rulebase and adds Management load, so save meaningful milestones. It includes published changes regardless of which client made them. It does not archive complete object definitions, permissions, or connector credentials and does not replace a Management backup.

3. Compare two saved versions

1. After the agreed change is published, save a second version of the same context, for example After Linux cleanup CHG-1042.
2. Select an older and a newer version in the list, then choose Compare selected versions. Check both labels and capture times.
3. Review added, deleted, modified, and moved rules or sections. Search by saved name or UID with at least two characters, or filter by change type.
4. Choose View changes to inspect the stored older and newer field values. These details are available to global viewers without opening an editor.

Comparison describes the two captured states. Runtime counters, locks, and rule-number shifts alone do not count as content changes. A rule can be both modified and moved. A referenced object's separate configuration is not a complete object-version comparison.

When coverage is shown for an automatic version and its reference version, zero unchecked publications means every publication in that interval was checked. A positive or unknown count means the difference can combine several publications. Use Published changes to investigate the interval; the first automatic baseline has no earlier coverage to establish.

Propose selected historical fields when needed

Continue here when you intend to make a new change using selected values from a saved version. Review that intent with the people responsible for the policy before opening the editor.

1. For an existing rule in the comparison, choose Use older or Use newer for the intended source version.
2. Check the source label and capture time. Select only the supported fields you intend to change and choose Preview selected fields.
3. Compare Current value, read from Management, with Proposed value, taken from the saved version. Read any Unavailable fields explanation.
4. Choose Open current rule in editor. Review the current rule and the proposed fields, then save or request approval through your authorized workflow.

Previewing and opening the editor save nothing. The editor checks current permissions, the edit lock, references, and whether the live rule still matches the preview. If the rule, publication, or access changes, prepare a fresh preview. Follow the resulting request or job to completion using Request and approve a change.

Selective restore supports existing rules and the fields offered in the preview. It cannot recreate deleted rules, restore sections or positions, reconstruct inline layers, or roll back object definitions. Missing or incompatible references cannot be restored. Publication and policy installation remain separate outcomes.

Optionally enable automatic history for an important context

In Saved versions, confirm the context and choose Enable automatic history. Enabling starts a baseline capture and makes you its owner. Wait for the baseline result, then check Owner, Check interval, Last check, and Last saved version. Use Refresh versions for current status.

Automatic history runs with the page closed and captures changed content after observed publications, including external publications. Unchanged checks need not create a version. The displayed check interval applies to your deployment. Enable only the contexts you need, because checking a new publication reads each enabled rulebase in full.

Several publications can occur between checks or before capture starts, so this does not guarantee a version for every publication. Review each version's coverage. If history is Suspended after its owner loses access, an eligible administrator can review the reason and choose Resume automatic history, becoming the owner. Disable automatic history stops automation and leaves saved versions available.

Keep important versions and plan archive maintenance

The displayed capacities apply to this context with its current connector credentials. Manual versions have a count limit; automatic versions have separate count and storage limits, removing the oldest automatic versions as needed. Automatic retention never removes manual versions. Use an automatic version's Keep action, optionally label it, and confirm Keep version to protect it as a manual version within manual capacity.

Manual versions remain until deliberately deleted. When full, an administrator with global rulebase edit permission must review retention needs before deleting an unneeded version. Confirm the exact version: deletion cannot be undone in the history page.

Changing the read credential, Management target or domain, or TLS identity can make earlier captures inaccessible through the current connection even when their names are unchanged. Before a planned rotation, review retention and verify the normal encrypted deployment backup. Afterwards, verify the connection and create a new capture. Do not reactivate a revoked key to retrieve history. Stored older captures remain in database backups; there is no supported transfer to the new credential or export across credential bindings.

For host maintenance of inaccessible captures, contact support for archive-maintenance guidance matched to your installed release. Use the release-matched backup guidance linked from Upgrades and recovery.

Resolve a history problem

• Missing history or unavailable actions: verify global permissions, license, exact context, write credential for restore, and any recent connector credential or target change. Team rule access alone is insufficient.
• Capture still running or failed: follow the existing job before requesting another capture. Review the displayed reason; capture limits do not produce a shortened saved version.
• Incomplete publication report: request a narrower date interval and review all available session pages. Preserve any remaining coverage warning in your conclusions.
• Comparison exceeds the response limit: choose a smaller page size. If one row is too large, it remains unavailable rather than being silently shortened.
• Expired restore preview: return to the intended comparison and preview again against the current rule. A copied or reloaded editor link cannot replay the historical proposal.

For traffic evidence after a change, continue with Logs and Watchlist. For unresolved failures, follow the support-request checklist with the affected step, versions, time, and sanitized error.