Escalation
When support is the right step
Support is most useful after you have already narrowed the problem inside the workspace.
Use support when the blocker survives the normal recovery loop
If preview restart, connector retry, or workspace inspection still does not resolve the issue, escalation is justified.
Do not replace basic diagnosis with a vague ticket
Support moves faster when you already know whether the failure is about preview, publishing, GitHub sync, billing, or another product area.
Open support from the same Flutty flow
The menu entry keeps help close to the project instead of forcing a context switch into a separate toolchain.
Form
What the support form asks for
The built-in form is intentionally simple, but every field should help support reproduce the situation.
Name and email
These identify who is reporting the issue and where a reply should go.
Topic
Choose the category that best matches the blocker so the request starts in the right queue.
Subject
Summarize the failing action, not the whole project history.
Message
Describe the exact action, expected result, actual result, and anything you already tried.
No automatic project attachment
The form does not automatically include a project snapshot or runtime state, so put that context in the message when it matters.
Quality
Write the message like a reproduction note
The best support requests read like a short debugging handoff.
- 01
State where you were working
Mention the project, route, or workspace surface involved.
- 02
Describe the single failing action
For example, publishing, loading preview, applying a GitHub remote update, or opening a database explorer.
- 03
Include the expected versus actual behavior
This saves one full back-and-forth cycle.
- 04
Mention the recovery steps already attempted
Support should know whether you already retried, refreshed, or checked the runtime state.