Collect useful support evidence

Product Zbix CRM · Version 1.2.0 · Source reviewed · Reviewed 28 October 2026
Audience Administrators and implementation teams · Deployment All supported models

Overview

A useful support request identifies the operation, expected behavior and safe evidence needed to reproduce the issue. It should separate user access problems from service or provider failures.

Purpose

Help administrators and support engineers diagnose the issue without disclosing credentials or changing records unnecessarily.

Prerequisites

• Permission to inspect the affected page.

• Administrator help for protected health, job and audit evidence.

Procedure

1. Record the date/time and timezone, module/page, operation and current record or job state. Describe the expected result and what actually happened.

2. Capture the exact displayed error text and a screenshot after removing confidential customer information and authentication material.

3. Record the application release/package version and, for administrators, the schema and runtime identity shown by System Health. Distinguish missing identity fields from a verified match.

4. Check the relevant troubleshooting article. For access problems, compare effective permissions and record visibility; for queued work, inspect worker heartbeat and execution history.

5. For email or Microsoft synchronization, include safe provider status, attempt outcome and whether the outcome is uncertain. Avoid automatic retries when a remote write may have succeeded.

6. Escalate through your organization’s approved support channel with the evidence and steps already attempted. Preserve existing records, volumes and logs until the owner approves a recovery action.

Expected result

Support receives enough context to investigate while protected information and existing application state remain intact.

Important notes

• Do not include passwords, TOTP codes, recovery codes, API tokens, cookie values, private keys, raw environment files or unredacted diagnostic exports.

• Do not treat a successful health probe as proof that every worker, provider and recovery path is functional.

• No support email address or service-level promise is inferred by this documentation. Use the contact route in your service agreement.

Troubleshooting

• Issue cannot be reproduced: provide exact filters, timezone, role scope and the sequence of actions.

• Only one user is affected: check that user’s active status, session, module role, team and provider connection before altering system settings.

Related articles

• Read System Health and verify service readiness

• Module Permissions

• Create and send Email Activities