Identify where the problem starts, then take the next safe step.

I cannot access my account

Customer portal at naradox.com

Use portal account recovery for invitation, password, and MFA problems.

• Use Forgot password for the portal account and complete any required email verification.
• At the MFA step, use your authenticator or one of your saved unused backup codes. If both are unavailable, use account support without signing in.
• If a required Terms review blocks portal access, ask an owner or billing admin to complete it. After acceptance, each member's role still determines which actions they may perform.

Your installed Naradox address

Portal password recovery does not reset a local Naradox account or an Entra identity. For local credentials, use the configured local recovery path. A host administrator can follow the First login recovery section in the installation's docs/INSTALL_ADMIN.md; required MFA is preserved. For Entra sign-in, involve your identity administrator.

Follow installed account recovery for the current password and authenticator options. For missing invitation or reset email, an authorized administrator can test the saved SMTP configuration.

Setting up a new operator or reviewer? Follow the participant account steps before assigning the first workflow.

The download, installation, or license is blocked

• Missing file or verification failure: use download recovery. Stop before extracting or running an unverified installer.
• Host, architecture, or HTTPS error: use installation recovery and the bundled guide for the selected release.
• License import, expiry, or capacity error: use license recovery. Changing a portal allocation does not update the installed file automatically.
• Interrupted upgrade or lost host: use upgrade and recovery guidance. Retain the original recovery point and operation evidence.

Keep account/payment issues separate from local installation failures. If the portal says a change was saved but its license could not be issued, check the saved state and offered retry before buying again or adding another deployment.

The connector fails or the expected rule is missing

1. Confirm the selected connector, Management URL, MDS domain if applicable, and API v2.1 support.
2. Use the connector's Check connection action and inspect its status and Last checked time. Review network reachability, read credentials, and the intended certificate trust when it fails.
3. When the connection check succeeds, check the selected package, policy family, and required layer. Verify that the rule is published in Management.
4. For a limited operator, ask the access administrator to check the current grant or team scope, field visibility, membership, and expiry. Connection health alone does not grant rule access.

A scope whose section boundaries cannot be verified must be reviewed by an access administrator. Use the available verification retry after the underlying problem is fixed; do not replace boundary identities or broaden permissions just to hide the error. Start with the Check Point connection guide when comparing setups.

Logs are empty or Watchlist cannot establish usage

1. Ask the firewall administrator to enable Log Indexing on the Check Point Management/Log Server and run Install Database before validating API log retrieval. A successful connection check does not validate indexed log availability.
2. Check the intended connector, rule or grant/scope context, time window, and current log permissions. Watchlist permission does not itself grant log access; hidden rule fields also restrict the log fields a limited account can inspect.
3. Retry the read after correcting its cause. For Watchlist, refresh usage or allow the configured collector to continue, then inspect the new coverage and status. A refresh attempt alone is not evidence of a completed measurement.

SmartConsole's Log File: Latest Log File reads a raw log file. Seeing events there does not prove that the indexed show-logs source used by Naradox has them.

Not checked yet, No log access, and Incomplete coverage do not establish zero matching records for the full period. Check the current measurement state and preserve the target, context, period, and coverage with any support request. A later log search can include records that arrived after collection; a differing count does not by itself show that a firewall change failed.

A change is pending, failed, or uncertain

• Pending approval: inspect the request's reviewer requirements. An individual approval does not complete a requirement needing more votes or another independent requirement.
• Approved or queued: follow the existing request. Approval and queue admission do not mean the rule has already changed; technical Jobs access requires separate permissions.
• Conflict with the live rule: refresh the current rule and review a new proposal. Do not assume the request's original snapshot is the latest live state.
• Apply failed: inspect the recorded reason and available retry/recovery action. The request may remain approved while execution needs recovery.
• Reconciliation required: an authorized operator must establish the vendor outcome using the product's recovery path before retry. A lost response does not prove that Check Point rejected the change.
• Published but not installed: inspect the separate policy-install request and its result. Check installation authority, connector targets, and any reported-change warning with the firewall administrator.

Keep the request or job reference and its current status. Avoid submitting duplicate changes while an outcome is unresolved. Follow Request and approve a change for the expected progression and completion checks.

Use policy installation and job recovery for installation checks, retry, cancellation, and reconciliation. For missing external audit events, follow audit-delivery recovery.

For object changes, check the separate lifecycle permissions and shared usage described in Manage Check Point objects. An authorized investigator can use Audit and evidence to trace recorded decisions and outcomes and preserve the relevant events.

Prepare a useful support or feature request

Open Requests in the customer portal and choose Support for a product, license, installation, or troubleshooting problem. Choose Feature request for a desired capability or workflow improvement.

• A clear subject, the business impact, and whether this is Testing, Staging, or Production.
• The Naradox version and whether the issue affects the portal or an installed deployment.
• For Check Point issues, the Management release/hotfix, API context, and affected workflow.
• The exact step, expected result, actual result, time and timezone, and relevant request/job reference.
• What changed recently and which safe troubleshooting steps you already tried.
• Sanitized screenshots or short log excerpts that show the error without unrelated customer data.

Do not send passwords, API keys, session tokens, MFA codes, private keys, raw license material, or full firewall configurations in an ordinary request. Use a minimal sanitized example. For a feature request, describe who is affected, the current workaround, and the desired outcome.

Without portal access, use account help. For commercial questions, contact sales.

Keep follow-up in the same conversation

Open the request from its history to read status, replies, and attachments, then add new evidence to the same thread while replies remain available. A role may be allowed to read without replying. A closed thread offers a new request; include the earlier reference when continuing that issue. Public enquiries receive follow-up by email.

See the support scope for what support covers.