Confirm what reached the gateways.

1. Prepare one reviewed installation

Use an account authorized to view the Rulebase and install policy globally for this administrator workflow. Connector management, rule editing, approval, and installation are separate permissions. A requester or reviewer can follow a change through Requests without gaining access to Jobs.

• Confirm the rule or object change was published. For an approved request, check Applied and refresh the live rule.
• Agree on the connector instance, policy package, policy types, target gateways or clusters, and the installation window.
• Confirm a working write credential and the intended Install targets in the connector configuration. Default targets apply to packages without a package-specific mapping.
• Check whether auto-install already scheduled work for the same package. Follow that job before submitting another installation.

Selecting Policy Targets uses the package's Check Point target selection; it is not a restriction to the requesting team's rules. Saving targets alone does not install anything. Keep auto-install off for the first manual pilot described in Connect Check Point.

2. Review the package, policy types, and targets

1. Open Rulebase, choose the intended connector and policy package, and select Install policy.
2. Check Policy package and Targets in the dialog. Correct connector configuration before continuing if the destination is wrong.
3. Select the required Access Control and/or Threat Prevention policy types. Review the cluster behavior setting with the firewall administrator.
4. Read the available installation history and Changes since last install. Resolve unexpected changes through your change process before selecting Install.

Installation applies each selected policy type across the package and targets, including other pending changes affecting them. It does not install only the rule you just edited. The installation action is separate from the rule-change approval workflow.

No baseline, unknown history, a shortened change list, or a summary containing only Naradox-recorded jobs and audit events limits what the preview can establish. A zero count does not prove that there are no other vendor changes. Check Point publication reports can also include changes elsewhere in the Management domain; use Rulebase history when investigating them.

3. Follow the installation's job

The queued confirmation means Naradox accepted the work. Open Job Center or Platform > Jobs and inspect the corresponding Install policyjob. Use the job reference, status and type filters to find the exact attempt; Job Center shows a recent selection rather than the complete history.

• Queued, Scheduled, or Waiting for Check Point: work is waiting for its execution time or available capacity. A deferred job resumes automatically; waiting does not prove a Check Point command was sent.
• Running: execution is in progress. Keep following the same attempt.
• Succeeded: inspect the result, selected policy types, targets, and any Check Point task warnings.
• Manual install required or Skipped: read the required action or skip reason. A completed background job can deliberately leave installation unperformed.
• Failed or Reconciliation required: inspect the error and vendor task evidence before deciding what happens next.

Available details include the connector, package, targets, policy types, task identifier and task status. Visibility and actions depend on current permissions; an operational job row can remain visible while its historical content is hidden. A platform operator can inspect deployment-wide work, but that role does not itself grant all underlying rule content or installation rights.

4. Verify deployment and traffic separately

Confirm the installation's terminal result for the requested policy types and targets. An exact successful Check Point task, including a success with warnings without contradictory target details, can confirm installation. Read warnings and retain the task and job references.

Then test the intended traffic behavior and, where authorized, inspect the relevant rule logs. A successful installation is not an application connectivity test. The Logs and Watchlist guide explains how to interpret matching traffic records. Keep the request, publication, installation result, and verification evidence together using Audit and evidence.

Install through an assigned scope or grant

With explicit Install policy permission and configured package targets, use the action for the selected scope in Team rules or the assigned grant in Granted rules. Naradox checks that exact source again when the job runs. The package-wide effect remains the same.

Limited installation checks the reported changes against the permitted rule or current scope rules. Other reported changes or unverifiable history block ordinary installation. Missing target publication times, incomplete reports, and a changed publication can all prevent a clear result. A clear check means no other changes were reported; it cannot guarantee that Check Point reported every policy effect.

Access, HTTPS and NAT contexts use Access Control installation. Limited Threat Prevention installation currently cannot establish its separate baseline and receives an unverifiable result. Global installation authority does not use this limited-source check.

Force policy install is a separate permission. When a check blocks installation, an authorized user may explicitly choose Force install policy after reviewing the complete package impact. This bypasses the reported-change check and can include changes outside the assigned rule or scope. It still checks current authority and targets, and records the force choice. Escalate a blocked check to the firewall administrator when that decision is outside your responsibility.

Enable automatic installation only after the manual workflow works

An authorized connector administrator can enable Enable auto-install with working write credentials and configured targets. The Coalescing window waits after the latest successful policy-relevant Naradox change, allowing several changes to share an installation. Rule changes identify their package; instance-wide object publishes need a configured default package or package-specific target mapping to identify their destinations.

Keep Don't install when changes were published outside Naradox enabled. Its guard needs a verified baseline covering the configured targets and matching successful Access Control and Threat Prevention installations. Establish that baseline through a reviewed manual installation of both policy types where appropriate. A dynamic target selection cannot establish the same proof of complete prior target coverage.

External publications, missing or inconsistent baselines, and unverifiable history can produce Manual install required. Read the reason and review a new manual installation; disabling the guard is not a routine recovery step. A rule or object publication remains successful if the automatic installation handoff needs manual attention. Follow both outcomes.

Resolve an uncertain installation before submitting another

Partial success, contradictory task details, lost responses, or an unknown vendor outcome can require reconciliation. A timeout does not prove that Check Point did nothing. Ask an operator with platform-management authority to open the affected job and use Reconcile.

1. Read the recorded task identity, status, and available target details. If details are shortened or absent, inspect the complete task and current policy state in Check Point.
2. Establish that the original execution finished and check every requested target. Resolve any remaining policy-install effect before acknowledging consistency.
3. Complete the job's review confirmation. For an uncertain result, add the optional review note or ticket reference when useful.
4. Select Close reviewed blocker only when the confirmation is true, then verify the refreshed job state.

Closing the blocker records the investigation. It does not install policy or dispatch a coalesced follow-up. Any further installation needs a fresh, reviewed request. A busy execution or competing installation can prevent closure until it finishes. Keep unresolved evidence and contact support rather than confirming a state you could not establish.

Choose the action offered for the current job

Jobs also follows rule application, exports, captures and other background work. Available actions depend on the job type, current attempt, state, and your authority.

• Retry: when offered for a safe failure, creates a new attempt and preserves the original as history. Follow Latest attempt; do not keep acting on an older failure. A failed policy installation needs a fresh installation request.
• Cancel: can stop eligible queued work and supported running jobs. It is not a general stop button for an installation already sent to Check Point, and does not undo vendor effects.
• Abandon intent: retires an eligible direct-rule change intent and releases its reservation. It performs no vendor rollback and is unavailable while the effect needs reconciliation.
• Reconcile: resolves an investigated uncertain outcome. Rule and object jobs have different evidence requirements from installation; use the fields shown for that job.

If an action completed but its display could not refresh, use Retry refresh. That reads the result again without resubmitting the action. For escalation, retain the job and request references, times, visible status and safe error text; follow preparing a support request.