Internal Escalation and Known Issues Guide

Use this support runbook to classify issues, collect evidence, avoid unsafe recommendations, and escalate to the right team.

Where to find it

Path: Help > Help Center > Internal Support, then open Known Issues when support-only guidance is needed.

This topic is a help or support guide rather than a transaction entry screen. Open it from the Help Center and search by the guide title or the main keyword.

Guide Summary

AudienceSupport staff, implementation team, AI agents, and developers.
Applies ToAll QBM support escalations, production incidents, customer troubleshooting, and developer handoff.
PurposeMake escalation consistent, evidence-based, and safe for customers.
Last Updated2026-05-18

Severity Levels

SeverityMeaningExamples
CriticalProduction is down or data integrity is at immediate risk.All users cannot login, database offline, posting corruption suspected.
HighMajor workflow blocked for a department or management report.QSalesView manager dashboard down, POS counters cannot close batch, invoices cannot print.
MediumImportant issue with workaround.One report fails, one workstation cannot print, one user permission issue.
LowQuestion, training, minor display, or documentation issue.How-to question, wording issue, non-blocking guide improvement.

Known Support Rules

  • If QBM Client login fails, fix QBM Server or SQL Server before troubleshooting QSalesView.
  • If QSalesView login times out, check QBMWServices, port 8053, Cloudflare Tunnel, QBM Server, SQL Server, ProductKey, and permissions in order.
  • If assemblies load from Dependent Dlls, this is expected and should not be changed unless development confirms a real bug.
  • Do not recommend exposing QBM Server, SQL Server, or local QBM ports directly to the public internet.
  • Do not ask customers for passwords, full product keys, tunnel tokens, or public full-database backups.
  • When a user says "Invalid Token", do not assume the account is deactivated. Check token expiry, reuse, broken URL, account mismatch, and incomplete password setup.

Expected result: Support escalates with correct severity, complete evidence, and no unsafe recommendation.

Escalation Targets

Issue TypeEscalate ToRequired Evidence
Service stopped, ports, Cloudflare, hostingServer support or implementationService status, port check, tunnel target, logs.
SQL errors, backup, restore, database offlineDatabase support or DBASQL error, instance, database, service status, backup status.
Reproducible app bugDevelopmentExact steps, version, logs, screenshots, expected vs actual.
Permission confusionImplementation or support leadUser, group, screen, action, comparison user.
Training or process questionFunctional consultant or supportModule, workflow, document, report, user role.

Troubleshooting Decision Tree

  1. Is data integrity or all-user login affected? Mark Critical and collect service/database evidence immediately.
  2. Is the problem limited to one user? Check user permissions and workstation before development escalation.
  3. Is the problem limited to one browser app? Check QBMWServices, tunnel, API URL, and permissions first.
  4. Is the issue reproducible after configuration and service checks pass? Escalate to development with exact evidence.
  5. Is the issue a known setup or training problem? Link the matching help guide and record the customer answer.

What To Send To Support

  • Exact message, screen, timestamp, and affected scope.
  • Versions and recent changes.
  • Logs and screenshots from the same time.
  • Configuration values with secrets masked.
  • Steps already tried and their result.
  • Business impact and available workaround.

Security Notes

  • Never include passwords, full product keys, tokens, or raw database backups in escalation notes.
  • Mask customer-sensitive data in screenshots before sending outside the immediate support team.
  • Use secure channels for approved database transfers.