Prepare a safe support case

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 Zbix CRM support case identifies the affected release, operation, user scope and time, then provides the smallest reproducible example. Existing records, operation histories and health evidence usually provide more useful context than a screenshot alone. Sensitive configuration and authentication material must remain outside the case.

Purpose

Use this checklist when a documented resolution does not restore the expected behavior or when an uncertain external operation requires review.

Prerequisites

• A reproducible symptom or a preserved failed operation.

• Permission to share the chosen demonstration or sanitized evidence with the support recipient.

Procedure

1. State the symptom, expected result and business impact. Include the module, visible action and whether the issue affects one user or several.

2. Record the product release and database migration from available approved evidence. If runtime identity is unreported, say that explicitly.

3. Provide the incident date, time and timezone. Include the safe error text and request identifier when available.

4. Describe the steps already taken, including refresh, permission review, job history and health checks. Identify any uncertain email or calendar outcome before further retries.

5. Attach a screenshot only after checking it for customer data, account recovery links, API tokens, authenticator secrets and private infrastructure information.

6. Keep the source record and operation history intact until the case is resolved. Agree on any test, retry or data correction before applying it to customer records.

Expected result

Support can reproduce or correlate the issue with a clear account of what is known, what remains uncertain and what actions have already occurred.

Important notes

• Never include .env contents, passwords, bearer tokens, private keys, recovery codes or full reset URLs.

• A demonstration screenshot can show an empty state accurately; it should not be replaced with fabricated records.

• Use an isolated test environment for mutation-based reproduction where feasible.

• A public forum or knowledge-base article is not an appropriate destination for private operational identifiers.

Troubleshooting

• The issue cannot be reproduced: preserve the original time and operation identity, then compare logs/history instead of repeatedly making changes.

• Support requests a destructive action: verify a recovery point and obtain the required operational approval before proceeding.

Related articles

• Operational logging and support evidence

• Read System Health and verify service readiness

• Troubleshoot queued failed or uncertain email

• Troubleshoot import validation and execution