> For the complete documentation index, see [llms.txt](https://thecontentforge.gitbook.io/thecontentforge-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://thecontentforge.gitbook.io/thecontentforge-docs/feature-guides/support.md). # Support & Feedback Support & Feedback is how you report bugs, request features, and get hands-on help from the team without leaving TheContentForge. Everything happens inside your workspace; reporting is only available to signed-in active users. ### Where it lives Three entry points: * **Sidebar menu** - `Report Issue` (bug) and `Request Feature` (feature) buttons near the help links * **Support Inbox** - `/support` shows every ticket you've opened, with status badges. Investor Intel workspaces use `/intel/support`. * **Inline error states** - failed AI jobs in the generation queue show a `Report` button that pre-fills a bug with the failing job id, status, and visible error Reporting is **not** available from the public landing, pricing, or FAQ pages - you need to be signed in. ### Bug reports vs feature requests * **Bug report** - Something is broken or behaving unexpectedly. Captures a title, description, severity (low / medium / high / critical), affected section of the app, impact scope (just you, one workspace, multiple users, or everyone), whether it's blocking your work, whether you have a workaround, and manual attachments. Uploads are limited to 10 files per submit or reply, 30 files per ticket, and 25 MB per file. The app automatically attaches diagnostics: browser, viewport, app version, current URL without query strings, and a short trail of recent activity events. * **Feature request** - Something you want that doesn't exist yet. Captures a title, description, category, impact scope, and attachments. Severity doesn't apply. The submission form keeps required fields short. A 3-character title and 10-character description are the minimums, but more context shortens triage time. The form also has a **Copy debug context** button that copies the technical diagnostics - and, for bugs, your recent activity trail - to your clipboard as JSON, handy when the support team or a teammate asks for it directly. ### Your Support Inbox `/support` is your personal inbox. Each ticket shows: * Reference code (e.g. `BUG-0042` or `FEAT-0017`) * Title and a snippet of the description * Current status badge * Last activity time Click a ticket to open `/support/:refCode` and see the full thread. ### Ticket detail and thread The ticket page shows the full submission, every comment, every attachment, and any system events (status changes, assignments, info requests). You can reply at any time: * **Composer** - Type a follow-up comment with up to 10 attachments per reply. Replies are scoped to your ticket and visible to you and the team handling it. * **Resolution banner** - If the ticket has been resolved, marked shipped, declined, or any other terminal status, the resolution note shows at the top. * **Needs info banner** - If support has asked a specific question, the question shows in a banner so it's obvious what to answer. ### Status meanings | Status | What it means | | ----------- | ----------------------------------------------------- | | Open | Submitted but not yet picked up | | Triaged | The team has reviewed and categorised it | | In progress | Someone is actively working on it | | Needs info | Waiting on a clarifying answer from you | | Planned | Feature request scheduled for future work | | Shipped | Feature request delivered | | Resolved | Bug fixed | | Won't fix | Bug acknowledged but won't be addressed (with reason) | | Declined | Feature request declined (with reason) | | Duplicate | Linked to another ticket already being tracked | ### Grant support access On an open ticket you'll see a **Grant support access** button. Clicking it lets the support engineer working on your ticket see your workspace so they can investigate hands-on - useful when a bug is hard to reproduce or you'd rather have someone look directly than walk you through it. You stay in control: * You grant access manually - it's not on by default * You can **Revoke** at any time from the same ticket card * It ends **automatically** when the ticket closes * It doesn't use one of your workspace's paid user seats * It is scoped to *that one ticket* - closing it doesn't open a back door for future work If you'd rather not grant access, you don't have to. Comments and attachments are usually enough. ### Notifications The support team receives a notification when you open a ticket, when you add a comment, and when you grant or revoke support access. Replies on your tickets surface in your Support Inbox. ### Workflow 1. Hit `Report Issue` or `Request Feature` from the sidebar menu, or click a `Report` button from a failed generation job 2. Fill in title and description; add severity, impact, and optional screenshots or logs as attachments 3. Submit - you'll be taken to the new ticket at `/support/:refCode` or `/intel/support/:refCode` 4. Reply to follow-ups, grant support access if asked, and watch for status changes 5. The ticket moves to a terminal status (Resolved, Shipped, Won't fix, Declined, or Duplicate) when it's done ### Tips * For bugs, attach a screenshot or screen recording - it usually shortens triage by a lot * Severity matters: reserve `critical` for "publishing is broken" or "data is at risk." Don't inflate severity to skip the queue; it goes against the way the team prioritises * If a bug isn't reproducible from your description, support may ask to use **Grant support access** - granting it is faster than a back-and-forth * Feature requests live longer than bugs. They flow through Planned → Shipped as roadmap allows; keep them focused on the problem you're trying to solve, not a specific implementation ### Who can use it Support is available to all signed-in active users in active workspaces. If your workspace is past its grace period or soft-deleted, support reporting is disabled until the workspace is restored. ### Related * [User Roles](/thecontentforge-docs/getting-started/user-roles.md) - every role can submit tickets; visibility on each ticket is scoped to the reporter and the support team * [Account](/thecontentforge-docs/feature-guides/my-account.md) - for billing or workspace settings issues, check the Account page first --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://thecontentforge.gitbook.io/thecontentforge-docs/feature-guides/support.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.