Validate one controlled change before broadening access.

1. Choose a safe pilot and its participants

• Choose the intended Management server, domain, policy package, and a rule suitable for a controlled test.
• Identify the Naradox access administrator, the operator who will request the change, and a different reviewer.
• Agree the allowed field and existing object, the expected result, and whether policy installation is part of this test.
• Keep installation permission with the firewall administrator for this pilot and coordinate with other people changing the same package. Have that administrator confirm that Enable auto-install is off for the connector instance so installation remains a separate manual decision.

Customer-portal roles do not grant these installed-product permissions. Use the accounts and access settings inside your deployment; see the account distinction.

Prepare the operator and reviewer accounts

A fresh installation starts with the installer's local administrator. Before assigning the pilot, an identity administrator opens Identity & Access > Users and prepares a separate account for each participant. Check that the installed license has capacity for them.

Follow the account onboarding steps to invite local users, create local accounts, or admit approved Entra users. Confirm that each participant can sign in before assigning the pilot.

Use No app role for these limited pilot accounts. The operator receives access through the rule grant below; the reviewer receives request access through explicit reviewer selection. Neither needs an administrator or Global change supervisor role for this pilot. Confirm both can sign in and complete any required MFA before creating the grant.

2. Add and check the connector

1. Have the connector administrator follow Connect Check Point to configure the intended Management server and domain, API credentials, and certificate trust.
2. Use Check connection and confirm Success with a current Last checked time for that instance. Saving its configuration alone does not prove a working connection.
3. For this change pilot, confirm that the write credential is configured and Enable auto-install remains off. Continue with the read-context check below before delegating access.

Expected result: the correct target and domain are reachable with read access. A successful connection check does not prove write permission, policy-install targets, or that every planned workflow has been tested. Resolve a failing connection before creating requests.

3. Confirm the read context

Open Rulebase with an authorized account. Select the connector instance, package, and policy family, then the layer where required. NAT uses the package without a layer selection. Confirm that the intended rule and its source, destination, service, and action are the ones you expect.

Naradox's rule view follows published Management state. Unpublished SmartConsole edits are not part of that view. After an external publication, use Refresh to obtain current state before reviewing or editing. Publishing a rule change and installing policy on a gateway are separate events.

4. Grant only the pilot access

1. As the access administrator, create an exact-rule grant for the intended user or team, including the correct package, family, and layer context.
2. Set the needed field to Edit and keep other fields at the intended View or Hidden level. Select the existing Check Point objects the operator may use.
3. Choose Approval and configure the required reviewers and approval count. Keep object creation and policy installation separate from this rule-edit permission.
4. If the pilot includes log evidence, enable the intended Rule logs and Watchlist permissions explicitly. Watchlist needs at least one visible supported object-reference field; rule-edit access alone does not enable either feature.
5. Sign in as the limited operator and open Granted rules. Confirm that the pilot rule and permitted choices are available, and other edits remain unavailable.

Firewall scopes are an alternative for a team-owned block of rules. Their verified section boundaries, field rights, and workflow determine access. Use the exact-rule grant first when the pilot needs only one existing rule; rule creation is a separate scope capability. Follow Access and permissions to configure a team scope with independent reviewers and check each participant's access.

5. Submit, review, and follow the result

1. The operator opens the rule, acquires the edit lock, chooses the allowed change, and submits it with a useful reason.
2. The selected reviewer opens the request in Changes, compares the original request snapshot with the proposal, and explicitly approves or rejects it.
3. All configured approval requirements must be satisfied before application starts. One vote is not necessarily final approval, and approval is not proof of completed execution.
4. Follow the request's execution status. Naradox rechecks current authority and the live rule before writing; wait for the applied result and the refreshed rule.

The requester can follow progress in My requests. Technical Jobs access requires separate permissions. If the rule changed meanwhile, refresh and review a new request. If execution is failed or uncertain, use the recorded recovery options; do not submit the same mutation again simply because the page timed out.

Follow Request and approve a change for a worked example covering the proposal, reviewer decisions, and completion checks. For a blocked attempt, see pending, failed, and uncertain results.

6. Decide separately whether to install policy

For this pilot, the firewall administrator reviews the published change and other pending changes affecting the package. Follow Install policy and follow jobs to check targets, review the package-wide impact, and confirm the installation. A Comments-only change need not require gateway installation; agree the intended outcome before starting.

Expected result: the separate installation job confirms its outcome. A published rule or approved request alone is not installation success.

7. Review the evidence and widen deliberately

Confirm who requested and reviewed the change, what the request proposed, and how application and installation finished. Follow Audit and evidence to investigate recorded events with an authorized account and preserve the relevant results. Request participation does not itself grant audit access.

Inspect rule activity

With the intended log permission, choose View logs from the rule's actions and select the time window covering the test. Follow Logs and Watchlist to inspect the events, add a watch in the pilot's grant context, and interpret its measurement period and coverage. Matching records can include blocked attempts; they do not prove successful application use. Resolve missing logs or uncertain coverage with log troubleshooting.

For an account with global Rulebase viewing rights, Rulebase history explains reported publications and comparing saved versions. Captures must exist before you can compare them; a team scope or grant alone does not grant archive access.

Record the pilot's successful and denied actions. Only then expand the selected rules, team scopes, reviewers, object permissions, or installation rights. If a step needs help, include its context in a sanitized support request.