> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ferrufino-tech-solutions.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Create your first case

> Step-by-step walkthrough to capture your first operational knowledge case with evidence and structured details.

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

<Steps>
  <Step title="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).
  </Step>

  <Step title="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.

    <Warning>
      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](/en/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).*
    </Warning>
  </Step>

  <Step title="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)"

    <Tip>
      Use specific batch numbers, dates, or system names so your team can quickly locate cases later.
    </Tip>
  </Step>

  <Step title="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

    <Note>
      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.
    </Note>
  </Step>

  <Step title="Add tags">
    Enter keywords to make your case discoverable:

    * `connector`
    * `hardware-failure`
    * `batch-processing`
    * `thermal`

    <Note>
      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.
    </Note>
  </Step>

  <Step title="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.

    <Note>
      Evidence is attached to a case that already exists, so the case must be saved once before you can upload anything to it.
    </Note>

    <Warning>
      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](/en/features/evidence).
    </Warning>

    <Tip>
      Evidence makes your case credible and helps reviewers understand context. Include at least one artifact.
    </Tip>
  </Step>

  <Step title="Submit the case">
    Click **Save as Draft** at the bottom. The case is now stored in your workspace.

    <Warning>
      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.
    </Warning>
  </Step>
</Steps>

## 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.

## Related pages

<CardGroup>
  <Card title="Invite your team" href="/en/guides/invite-team" />

  <Card title="Troubleshooting" href="/en/troubleshooting" />

  <Card title="Contact support" href="/en/contact" />
</CardGroup>
