Skip to main content
Cases are the fundamental building blocks of FTS. Each case documents a specific operational problem, solution, or best practice in your technical operations with structured evidence and review workflows.

What is a Case?

A case is a self-contained knowledge record. The list below is the complete set of fields the create form writes; the length limits come from createCaseSchema.
  • Title: a clear, descriptive headline. Required, at most 200 characters
  • Observation / Symptoms: what was seen. The only mandatory text field, at most 10000 characters
  • Root Cause: why it happened. Optional, at most 10000 characters
  • Resolution / Steps Taken: what fixed it. Optional, at most 10000 characters
  • Severity and Category: one value each from your organisation’s taxonomy. Optional
  • Language: English or German
  • Workspace: the workspace the case is filed in. Required
  • Tags: free-text labels, any number, typed in the create form — the case is saved first and the tags are attached to it immediately afterwards, so that a failing tag cannot lose an already created case (new-case-form.tsx). You do not have to save first; unlike Evidence
  • Evidence: supporting files — photos (JPG, PNG, GIF, WebP) and PDFs only; a log file or a measurement table has to be converted to a PDF or photographed first
  • State: tracks the case through its lifecycle
There is no field called Body. Until 06.08.2026, now retracted, this list named one — “Body: detailed narrative explaining the problem, solution, or process” — and the German version of this same section invented a different one, “Schritte” (Steps). Neither exists. A case carries the three separate text fields above, which is what Concepts and Quickstart have said for several rounds. All three are plain text: no Markdown is rendered, anywhere in the product.

Case Lifecycle

Cases progress through five distinct states:

Draft

Initial creation. Visible to every member of your organisation — not only to you — and findable in search. Edit freely.

In Review

Submitted for review. Nobody is assigned — every member whose role is Reviewer or Admin is notified, and the first one to decide ends the review.

Verified

Approved by reviewers. Considered reliable knowledge ready for publication.

Published

Active in your knowledge base. Discoverable via search and browsing.

Deprecated

Marked as outdated. Archived for historical reference, not recommended for new use.
No status blocks editing, and there is no separate control for moving a case backward. Editing is what moves it: saving a case that is In Review, Verified or Published sends it back to Draft and clears its verification, so it must be reviewed again.

Creating a Case

Click New Case in the dashboard. You’ll enter:
  1. Workspace – required; the case is filed here
  2. Case Title – be specific and descriptive
  3. Observation / Symptoms – required. Plain text; include context, steps, outcomes and lessons learned
  4. Root Cause and Resolution / Steps Taken – optional, plain text
  5. Severity, Category, Language – optional, picked from lists
  6. Tags – free text, any number
  7. Evidence – attach after the case is saved
Until 06.08.2026, now corrected, the second step above read: “Body – use markdown for formatting”. Both halves of that sentence were wrong: there is no Body field, and Markdown is not rendered anywhere in the product — not in the case view, not in the PDF export. Line breaks are kept; ###, **bold** and tables are shown as the characters you typed.
Use templates if your organisation has them. A template pre-fills Observation / Symptoms, Resolution / Steps Taken, severity, category and tags — the five fields CaseTemplate actually carries. It does not pre-fill Root Cause: until 06.08.2026, now corrected, this said templates pre-populate “Root Cause”, and there is no rootCauseTemplate. Templates belong to the organisation, not to a single workspace.

Editing Cases

Open a case and click Edit Case. You can edit a case in any state, including a published one — but saving a change to a verified or published case returns it to Draft and clears its verification, so that no reader ever sees a “verified” badge on text nobody has reviewed. Every edit is recorded in the case history.
Once a case is Published, other team members may be relying on it. Always check the audit log before making significant changes.

Case Templates

If an admin or reviewer of your organisation has created case templates, you’ll see template options when creating a new case. FTS ships none: every template in your list was written by someone in your organisation, under Settings, section Case Templates. (Until 06.08.2026, now corrected, this said “your workspace admin”. Two things were wrong: CaseTemplate is keyed by organisation, so a template is visible in every workspace of the organisation — and reviewers may create one too, not only admins.) Using a template:
  • Pre-fills common sections and structure
  • Ensures consistency across similar cases
  • Speeds up case creation

Audit Log

Every case maintains a complete history. Open Case History in the case view to see:
  • Creation and modification timestamps — the case view shows the most recent 200 entries
  • Who made each change
  • State transitions (Draft → In Review, etc.)
  • Each review event. The reviewer’s written comment itself is shown in the separate Reviews panel below the history — and it is the only comment a case carries
This transparency ensures accountability and helps you trace how knowledge evolved.

Best Practices

Instead of “Equipment Issue,” use “Motor Bearing Failure: XYZ-2000 Unit, March 2026.”
Explain not only what happened but why it matters and what was learned.
Don’t wait until review. Attach photos and PDFs as you document.One data-protection fact before you do. On the Team plan and above, FTS reads uploaded images and PDFs with text recognition, 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 attach it — see Evidence.

Next Steps

Evidence

Learn how to attach and organize supporting files.

Review Workflow

Understand how cases move through approval cycles.