Support, troubleshooting, and known issues

Bug report vs feature request

The difference matters because broken behavior and missing capability usually need different review posture from the start.

Who this is for: Users deciding whether they are seeing something broken or asking for something new.

Last reviewed 2026-04-30 · Source of truth: broader help library · Languages: en, es

Article metadata

Product area: support and escalation

Owner: Support operations

Parity reviewer: Bilingual launch review

Retrieval-ready: Yes

What to expect next

Choose bug report when the current path appears broken, and feature request when the real issue is missing capability.
If you are still unsure, describe the current behavior first and let the structured route preserve that signal clearly.

When it is a bug report

Use a bug report when the current experience appears broken, inconsistent, or unexpectedly blocked compared with the intended path.

A bug report should preserve reproduction context instead of only describing frustration.

When it is a feature request

Use a feature request when the workflow gap is real, but the product is not actually malfunctioning relative to its current scope.

Feature requests should focus on the desired outcome and why the gap matters, not present a missing feature as if it were broken behavior.

Escalation path

If the issue could be both broken behavior and a sensitive operational blocker, route it through the clearer support or bug lane first instead of forcing certainty too early.

Related next steps

Open bug report intake Open feature request intake Open Spanish version Back to help center