Support, troubleshooting, and known issues

Report a blocked task clearly

A good blocker report should show what you were trying to do, what you already tried, and why the consequence matters.

Who this is for: Users who need structured support after help or the assistant did not fully resolve a task.

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

Use structured intake once you can name the blocked task, attempted steps, and operational consequence clearly.
Escalate faster when the blocker affects migration confidence, permissions, billing, or another consequence-heavy area.

What to include first

Name the blocked task, the product area, and the step where the workflow stopped feeling safe or useful.

List the help article, assistant answer, or product steps you already tried so support does not need to reconstruct the path from scratch.

What makes a blocker report useful

A strong report explains the consequence, such as delaying a trial, migration, setup, or stakeholder decision, instead of only saying something feels off.

It should reduce guesswork without turning the request into a giant dump of sensitive or low-signal detail.

Escalation path

If the task is blocked and continued retrying would increase confusion or risk, use structured intake instead of waiting for the issue to get noisier.

Related next steps

Open support or troubleshooting intake Read when to stop retrying and escalate Open Spanish version Back to help center