Follow a rule change from proposal to confirmed result.

1. Prepare one existing-rule change

Complete Access and permissions first. Use the prepared Linux firewall scope and a suitable existing Access Control rule within its verified boundaries. The scope must use Approval, with the Security team selected as a requirement needing one approval. Keep self-approval disabled for this example.

• The requester is an active Linux team member with permission to view the rule and edit its Comments field.
• The reviewer is a different active person in the selected Security team. Reviewing this request does not require Linux membership or a broad app role.
• The connector has working read and write credentials, and the participants agree which connector, package, layer, and rule they are using.
• For this manually controlled pilot, have the firewall administrator confirm that Enable auto-install is off for the connector instance.
• Choose a useful comment update, such as a maintenance owner and an internal change reference. Preserve existing information that still matters.

This example needs no new rule or object. A comment change lets you check the approval flow without changing the rule's traffic-matching fields. For a first connector setup, use the connection and read-access steps.

2. Submit the request as the Linux operator

1. Open Workspace > Team rules, select the prepared Linux scope, and find the agreed rule. Check its context and current values before opening Edit / request change.
2. Wait for the editor's access checks to finish. If another person holds the edit lock, coordinate with them before continuing.
3. Update Comments with the agreed text. For example, append Maintenance owner: Linux team; change reference: CHG-1042. to the existing comment.
4. Enter a useful Request reason, such as Document the maintenance owner and change reference for this existing rule. The reason is optional, with a limit of 2,000 characters, and is stored separately from the rule comment.
5. Check the draft, choose Request change, and confirm that the request was accepted. Open Workspace > Requests > My requests to follow it.

Expected result: the request is Pending. The rule table keeps the live rule and marks its pending change; proposed values are shown separately where available. Submitting the request has not applied the new comment.

3. Review the proposal as the Security reviewer

1. Open Changes and select the request. Confirm the requester, creation time, rule, and Scope context.
2. Read the Field / Before / Proposed comparison and the Request reason. Use Only changed fields to focus on the edit, then check that it matches the agreed intent.
3. Read Review status to see the configured requirements and decisions already recorded.
4. Optionally enter your own Reason, then choose Approve or Reject. Confirm the resulting status or recorded decision.

Before is the snapshot saved with the request. It is not a fresh read of the rule. Naradox checks current access and the live rule again before applying an approved change; review the proposal on its merits without treating its original snapshot as proof of today's state.

In this example, one eligible Security reviewer satisfies the single requirement. With multiple requirements, all must be met before application starts. Each person can fill at most one required approval across the request, even when they belong to several selected teams or roles. The requester cannot approve their own request unless an access administrator explicitly configured that individual exception.

Visibility alone does not make someone eligible to approve. A Global change supervisor can view and reject pending requests, but approval still requires selection in the applicable workflow.

4. Follow the request until the change is applied

The requester follows My requests; the reviewer follows Changes. Open request details to inspect review progress, application errors, and available execution information. These views work without access to the technical Jobs workspace.

• Pending: the request still needs approvals. A recorded vote may satisfy only part of the workflow.
• Approved: all approval requirements were met and application was queued. It may be waiting, running, or need recovery; check its execution information.
• Applied: Naradox confirmed the change in Check Point's published Management state. Confirm the refreshed live rule as well.
• Rejected or Revoked: the request ended without proceeding to application. Read the recorded decision before preparing another proposal.

Open pending and approved request details refresh their status automatically while the tab is visible. If a status check fails, use its inline Retry. Returning to the request is also a way to check the current result after navigating away.

The rule's Pending change indicator can remain during approval, application, and the subsequent rule refresh. If application succeeded but refreshing the rule failed, retry the refresh. Do not submit the same change again to make the display catch up.

5. Decide separately whether to install policy

Publish commits changes to Check Point Management. Naradox's rule view follows that published state; private, unpublished SmartConsole edits are not part of it. Install Policy deploys the selected policy type to the configured gateways or clusters. An Applied request is not proof that this separate installation succeeded or that traffic behaves as intended.

For the comment-only example, verify the published comment and agree with the firewall administrator whether any installation is needed. Installation affects the selected policy type across the package and targets, including changes beyond this team's rule. Keep that decision with the administrator for this example. Follow Install policy and follow jobs for reviewing targets, the limited-installation check, auto-install, and the separate terminal result.

6. Verify and record the result

1. Confirm Applied in the request and the new comment in the successfully refreshed live rule.
2. Keep the request reference, its reason, reviewer decision, and application outcome with your change record.
3. If policy installation was part of the change, confirm its separate outcome and test the intended traffic behavior. Inspect authorized rule logs for the relevant period when available.
4. Use a new request for a subsequent correction. Check the current rule before proposing it, and keep the original request as history.

For an authorized investigation of the recorded decisions and execution, follow Audit and evidence. An event confirming an approval records that decision; check the application and installation outcomes separately.

Log and Watchlist access are separate permissions. Matching log records may include blocked attempts, so a hit alone does not prove successful application use. Follow Logs and Watchlist and log and Watchlist troubleshooting when gathering that evidence.

Use Rulebase history with an authorized account to investigate reported publications or compare saved versions. Historical values can become a new proposal through the current rule editor and its normal workflow.

Request a new rule in an authorized team scope

After the existing-rule pilot, an access administrator can separately enable Create rules on an active Access Control or HTTPS Inspection scope. Keep its intended Approval requirements configured. Grants cannot create rules. Rule creation does not grant object creation or installation rights.

This permission allows the complete applicable new-rule form; the existing-rule field settings apply after creation. For example, enabling it on the Comments-only pilot authorizes more than composing a comment. Review that broader responsibility and the scope's allowed object selections before granting it. Existing Selected/All object boundaries and exclusions still apply.

1. Open the intended scope in Team rules and choose New rule, or use a rule's Add rule above or Add rule below action.
2. In Position, choose the placement and, when needed, an existing reference rule. Check the destination layer and expected-position preview. Above or below an Apply Layer rule creates a sibling; Add rule in layer enters that rule's referenced inline layer.
3. Complete the applicable fields, including source, destination, service, action, tracking and installation targets. Review Enabled explicitly and enter a useful request reason.
4. Select Request rule. Follow its proposal through My requests and the same reviewer decisions and application checks described above.

Top and bottom placement stay inside the root scope's markers; inline placement must remain reachable through that scope. To place a rule before an existing Cleanup rule, choose Add rule above on that rule. The displayed expected number describes submission order, and can change before execution. Use the named reference and layer as well as its number.

A pending new rule appears as a proposal, without a published rule number or live rule actions. A notice keeps it reachable if its position is outside the loaded rows. Confirm Applied and the refreshed live rule before treating it as present. If publication, placement or authority changes invalidate the draft, reopen creation in the current scope and review the intended position again.

Naradox appends [naradox change_id=…] to the comment of every rule it creates. It uses this marker to recognize the created rule if an attempt is interrupted, so keep it until the change is applied or reconciled. Reviewers can find the change later by pasting the marker or its ID into Change ID on Changes.

Use approval for general Rulebase work

The Rulebase operator app role can propose general Rulebase changes and requires approval. An access administrator opens Users > Edit user > Access > Rulebase Change workflow and configures explicit reviewer requirements for that person. The app role determines whether editing is unavailable, requires approval, or is direct; the workflow section does not grant or override those role permissions.

Select the connector, policy package and required layer in Rulebase, open the intended operation, and review the exact proposed change before submitting it. Follow the request in My requests; selected reviewers use Changes. Missing reviewer configuration blocks submission, with no fallback to a default reviewer.

The user's Rulebase workflow applies to general rule create, update and delete, sections, and Threat exception requests. Rule deletion, section operations and Threat exception creation or deletion require global Rulebase authority; a team scope or grant cannot supply it. Requests made through a scope or grant keep that source's own workflow. Selecting someone as a reviewer gives access to the relevant request and snapshots, without general Rulebase editing or object-catalog access.

Withdraw or replace a proposal while it is pending

If the requested change needs correcting, the requester opens its details in My requests and chooses Revoke request. Confirm Revoked, reload the current rule, and submit a new proposal with the corrected intent. Reviewers use Reject when the pending request should not proceed.

Revocation and rejection end the whole request, including after a partial approval. They do not withdraw only one person's vote. Once the request is Approved, these actions are unavailable. Follow the existing application attempt to its outcome before proposing a follow-up change.

Resolve the specific blocker

• The rule or edit is unavailable: check the selected scope and rule. Ask the access administrator to verify current membership, field rights, and scope boundaries. Use Check again when offered after the underlying issue is resolved.
• There are too few eligible reviewers: ask the access administrator to check the workflow and active reviewer membership. Approval requirements still apply; a broad role does not replace missing reviewers.
• The live rule changed: review the current rule and resolve the old request through the available workflow. A changed baseline requires a fresh proposal and review.
• Apply failed: retain the request reference and error, and involve an authorized operator. The request may remain Approved while its execution needs recovery. A safe retry can continue the approved request without a new vote when its authority and approvals remain valid.
• The outcome is uncertain: an authorized operator must establish what Check Point actually did. If the job shows Reconciliation required, use that recovery path before retrying. A timeout, lost response, or failed job does not prove the change had no effect.

Job inspection and recovery require separate operational permissions. Being the requester or final approver does not automatically grant them. Give the operator the request reference, visible status, time, and error so they can inspect the existing attempt without creating a duplicate. See job actions and recovery, pending or failed changes and preparing a support request.