Skip to main content
Your first case is the foundation of your team’s knowledge base. Follow this walkthrough to document a real operational incident or failure.

​
Example: A connector burn failure

Imagine your technical team discovered a connector malfunction on batch #2847. This is perfect case material—it involves a clear symptom, root cause, and corrective action.

​
Creating the case

1

Navigate to the Cases section

Log in to FTS and click Cases in the left sidebar. You’ll see an overview of all cases in your workspace (or an empty state if this is your first).
2

Click 'New Case'

In the top-right corner, click the blue + New Case button. The form has exactly these fields: Workspace, Title, Observation / Symptoms, Root cause, Resolution, Severity, Category, Tags and Language. The first three are mandatory; the case cannot be saved without them.Above those fields the form carries a Use a Template section. It is not a field of the case — picking a template pre-fills severity, category, tags and the observation and resolution text, and every pre-filled value stays editable. Leave it alone to start from an empty form. Templates themselves are created in the Case Templates settings area.
There is no field called body, and an earlier version of this line said there was. A case has three separate plain-text fields — Observation / Symptoms, Root cause and Resolution — and only the first is required. Evidence is not part of this form either; it is attached after the case has been saved (see the Attach evidence step below). The same list is on Concepts.The template section was missing from this page until the summer of 2026, while the word “exactly” claimed the list was complete. The German version of this guide has always named it as its own step (open item #349).
3

Enter the case title

Write a clear, concise title that summarizes the failure. Examples:
  • “Connector burn failure on batch #2847”
  • “Database replication lag during peak load”
  • “Authentication service timeout (2026-04-10)”
Use specific batch numbers, dates, or system names so your team can quickly locate cases later.
4

Fill the three text fields

The three text fields are separate on purpose — put each part of the story where it belongs, or the case will render with empty sections:Observation / Symptoms (required)
  • What: connector overheated and stopped accepting input
  • When: April 10, 2026, 14:32 UTC
  • Where: production environment, batch processing cluster
  • Impact: 47 units delayed by 2 hours
Root cause (optional — leave empty if unknown)
  • Thermal paste degradation plus a firmware bug in version 3.2.1
Resolution (optional)
  • Updated firmware to 3.2.2, replaced thermal paste
  • Added monthly thermal inspections to the maintenance schedule
All three are plain text. Markdown is not rendered anywhere in the product, in the app or in the PDF export — a # you type is a # your team reads.
5

Add tags

Enter keywords to make your case discoverable:
  • connector
  • hardware-failure
  • batch-processing
  • thermal
Tags are case-insensitive and can contain hyphens or underscores. You filter by a tag later by clicking it under Popular tags: above the case list — a tag typed into the search box does not find the case, because the search index does not contain tags.
6

Attach evidence

Open the saved case and use the Evidence panel. Upload supporting files:
  • Photos of the failed connector (JPEG, PNG, GIF, WebP — up to 5 MB each)
  • Reports, sensor logs or a firmware changelog as a PDF (up to 20 MB each)
You can drag and drop files onto the panel or click + Upload File to browse. Spreadsheets, CSV files and videos are refused — convert them to PDF first.
Evidence is attached to a case that already exists, so the case must be saved once before you can upload anything to it.
This is a data-protection fact, not a feature note. On the Team plan and above, FTS reads uploaded images and PDFs with text recognition shortly after upload, and the file itself is sent to Anthropic in the United States for that step. Your database and your files are stored in the EU; this one step is not. If a document must never leave the EU, do not upload it as evidence. The detail is on Evidence.
Evidence makes your case credible and helps reviewers understand context. Include at least one artifact.
7

Submit the case

Click Save as Draft at the bottom. The case is now stored in your workspace.
Every case is visible to every member of the organisation, in every role. There is no per-case visibility setting and no “internal-only” marking — a tag changes nothing about who may read it. If something must not be seen by the whole team, do not put it in a case.

​
What happens next

A saved case is a draft. To move it forward, open it and click Submit for Review: it changes to In Review and appears in the review list of every member of your organisation whose role is Reviewer or Admin. The review workflow is identical on every plan — Starter, Team and Enterprise alike. There is no configurable multi-reviewer process, no reviewer assignment and no approval gates: a single review decides, either Verify or Request changes, and publishing afterwards is a separate, manual step. Once the case is published, your team can search for it and reference it when similar failures occur. Written feedback travels in the reviewer’s comment on that review — there are no free-standing comments on a case.

Invite your team

Troubleshooting

Contact support