Use the right object and understand its reach.

1. Agree the change and prepare its permissions

Start with the reviewed Linux scope from Access and permissions. That example permits Comments only and leaves object management disabled. Before continuing, agree the destination change, its traffic impact, and any new host definition with your firewall administrator. Use an appropriate pilot rule and address assigned by your organization.

An access administrator opens Identity & Access > Teams > Linux > Firewall scopes and edits the intended scope:

1. Confirm the connector, package, Access Control layer, and live scope boundaries. Set Destination to edit under Existing rule access; retain the agreed visibility of the other fields.
2. Under Object permissions, use Selected Check Point objects and Browse to authorize the existing objects needed for the change. Preserve other selections needed by the scope.
3. If a new host is required, enable Allow creating objects. Set or retain the required Object name prefix, for example LINUX_. An established scope prefix is immutable; choose it deliberately.
4. Where appropriate, configure Allowed IP ranges for the team's permitted network addresses. Keep Allow editing objects and Allow deleting objects off for this create-and-select example.
5. Retain Approval and the intended Security reviewers under Change workflow, then save. The connector needs a working write API key. Keep connector Enable auto-install off for this manually controlled pilot.

Selected objects define which existing objects the scope may use, edit, or delete; the lifecycle checkboxes independently allow those operations. All Check Point objects broadens that boundary to supported objects except exclusions. Switching modes clears draft selections and exclusions, so review the result before saving.

Allowed IP ranges constrain network-object creation and editing. They do not filter existing objects selected in rules. Empty ranges add no address restriction; approval cannot override a configured range. A name prefix controls creation names and does not itself grant object access.

2. Look for the existing destination first

Sign in as the Linux operator. Open Workspace > Team rules, select the intended scope, and edit the pilot rule. Open Browse beside Destination. For an exact-rule grant, start in Granted rules instead; that grant supplies the permissions.

1. Search by a meaningful part of the object name and inspect its details. Check its type, address or subnet, and the connector context; a familiar name alone is insufficient.
2. For a group, inspect its membership before using it. A group can represent more destinations than its name suggests.
3. Select the intended object and apply the selection to the rule editor. Confirm whether the proposed change should add to or replace the existing destinations.

Selecting an existing object requires no permission to edit its definition. Likewise, being able to inspect an object does not imply permission to select, create, edit, or delete it. The available choices depend on your scope, the rule field, and the supported Check Point object type.

If the correct object already exists, continue to the rule request. If it is outside your selected objects, ask the access administrator to review its delegation rather than create a duplicate.

3. Create a host only when one is needed

In Destination Browse, choose New object and select the host type. Use the configured name prefix and an agreed descriptive name, such as LINUX_app_server. Enter the actual assigned address under IPv4 address or the corresponding IPv6 field, then review any comments and tags. Choose Create and wait for the result.

Create publishes the host to Check Point immediately. It is a separate operation from the rule request, even when the scope uses Approval. Canceling the rule editor does not remove that host. Treat object creation as an authorized firewall-management change in its own right.

After success, verify the new host's details and selection in Browse, then apply it to the rule editor. Naradox normally selects the created object, but a selection limit can prevent that. Adjust the intended selection before continuing. Do not create a second host just because it is absent from the draft.

Successful scoped creations are added to the scope's Selected objects, including when All mode is active. Disabling Create later does not remove that selection. Automatic NAT settings require unscoped administrative authority and are unavailable in this delegated host workflow.

4. Submit and review the rule change

Review the complete proposed Destination value, especially existing destinations that the change might remove. Submit the rule change through the scope's Approval workflow. Follow Request and approve a change for submission, review, and request statuses.

The Security reviewer checks the before/proposed comparison and inspects the referenced object. Confirm its address and the intended traffic impact, including the rule's Source, Service, Action, and placement where visible. Object creation success does not approve this rule change. All configured approval requirements must be met before application can proceed.

The operator follows the request in My requests. An Approved request may still be waiting for application. Wait for Applied and investigate any apply failure before considering the change complete.

5. Confirm the live rule and installation outcome

Refresh the live rule after application and inspect Destination again. Verify the intended host and address, alongside any destinations that should remain. Record the rule request and, if you created an object, that separate creation event. See Audit and evidence for investigating the recorded activity.

Publishing an object or applying a rule request updates Check Point Management; it does not by itself establish that gateways are enforcing the change. Have an authorized operator follow the policy installation workflow and verify the resulting job. An enabled connector auto-install policy can schedule installation after a publication independently of this operator's manual installation rights.

When an existing object needs editing

First determine whether the shared definition should change or whether the rule should reference a different object. Changing a host address, group membership, or service definition can affect every rule that uses it, including rules outside the operator's visible scope.

A scoped edit needs Allow editing objects, an authorized selected object or All boundary, and a supported type. Open the object in Browse, inspect its current details, and use the available edit action. For network, service/application, and content objects, Naradox checks current usage before choosing the execution path:

• Unused object: a permitted edit follows the direct path, including under an Approval scope.
• Used object: a scoped edit requires an Approval source with eligible reviewers and creates an object-change request. A Direct scope cannot bypass this requirement.
• Usage or current authority cannot be verified: resolve the reported failure; missing information is not evidence that the object is unused.

Follow the object request through My requests; the reviewer follows it in Changes. The saved proposal, current permissions, object identity, baseline, and usage must remain valid when it is applied. Approval does not override an IP boundary or grant broader object rights. Certificate and other administrative object workflows have their own supported actions; do not assume every object edit uses this request path.

When an unused object can be removed

Cleanup requires separate deletion permission and an authorized, supported object. Used-object deletion through a grant or scope is blocked. Have the firewall owner review and remove or replace its references through the appropriate change workflows before attempting cleanup.

Once the object is verified unused, open its current details, check the target carefully, and use its available delete action and confirmation. Removing an object from Selected, disabling a scope, or removing a grant removes access through that source; it does not delete the Check Point object. Other assignments may still grant access. Cleanup is a separate task, including for a host created before a rule request was canceled or rejected.

Understand unavailable actions and recover safely

Browse works, but Create or Edit is unavailable

Check the selected scope or grant, editable reference field, lifecycle permissions, object boundary, and connector write configuration. Some visible types are browse/select only. Dynamic objects and Security zones, for example, have no management actions in the current UI.

The address or object type is rejected

Review the configured IP ranges and proposed definition. With an address boundary, new network objects need explicit addresses or ranges. Edits to hosts, networks, and address ranges must leave their resulting addresses inside that boundary. Group and DNS-object access remains governed by the object permissions.

Change pending approval or Approved change not applied

Use View request from the error to inspect the existing object request. Resolve its review or application failure before starting a competing edit.

The result of a save is uncertain

Inspect current object details and the existing request or reported operation before retrying. Keep the error and request reference for workflow troubleshooting; repeated creation or deletion is not a recovery check.

Global administrators can also open Browse from Rulebase for supported management actions. Availability varies by object family and vendor restrictions. Network feeds explains the separate administrative workflow for externally supplied or locally hosted address lists.