Skip to main content
Wenn du diese sechs Konzepte verstehst, bist du produktiv in FTS. Jedes Feature im Produkt baut darauf auf.

​
1. Organisation und Workspace

Eine Organisation repräsentiert dein Unternehmen in FTS. Sie besitzt das Abonnement, die Abrechnungsbeziehung und die globalen Einstellungen. Ein Workspace ist ein Container innerhalb einer Organisation. Er enthält Cases, Mitglieder und eine Taxonomy. Denke an ihn als Projekt, Werk, Produktlinie oder Abteilung — was auch immer für dein Team Sinn ergibt.
Die Trennlinie verläuft um die Organisation, nicht um den Workspace. Daten einer Organisation sind strikt von denen jeder anderen Organisation getrennt. Innerhalb einer Organisation gilt das nicht: Wer Mitglied der Organisation ist, sieht alle ihre Workspaces — eine Einladung je Workspace gibt es nicht, Einladungen gelten immer für die ganze Organisation. Eine frühere Fassung dieses Kastens versprach das Gegenteil („kann nichts in Workspace B sehen, es sei denn, er wird explizit eingeladen”); das war falsch.

​
2. Case

Ein Case ist die atomare Wissenseinheit in FTS. Jeder Case hat:
  • Einen Titel. Ein eigenes Zusammenfassungsfeld gibt es nicht
  • Drei Textfelder — Beobachtung / Symptome, Ursache und Lösung. Pflicht ist nur das erste. Es sind einfache Textfelder, kein Rich-Text: Markdown wird nicht gerendert, Code-Blöcke, Tabellen und eingebettete Bilder gibt es nicht. Bilder hängen Sie stattdessen als Nachweis an
  • Einen Schweregrad und eine Kategorie aus der Taxonomie
  • Einen Zustand (Draft, In Review, Verified, Published, Deprecated)
  • Tags aus einer Liste, die die ganze Organisation teilt — hier stand bis zum 06.08.2026 „aus der Workspace-Taxonomie”; eine Taxonomie je Arbeitsbereich gibt es nicht (TaxonomyConfig ist auf die Organisation geschlüsselt, model Tag trägt überhaupt keine Zuordnung)
  • Angehängte Evidence
  • Ein vollständiges Audit-Trail (wer hat wann was gemacht)
  • Optionale Verlinkungen zu anderen Cases (für Muster, Abhängigkeiten, Follow-ups)
Die Löschfunktion löscht einen Fall nicht wirklich: sie setzt seinen Status auf „Archiviert”, er bleibt lesbar und sein Verlauf bleibt vollständig. Eine Verschiebe-Funktion gibt es nicht — ein Fall lässt sich nicht in einen anderen Arbeitsbereich verschieben, und „Archiviert” ist kein dritter Zustand neben dem Enum-Wert DEPRECATED, sondern genau dieser unter seinem deutschen Namen. Das ist kritisch für regulierte Branchen und für langfristige Wissensbewahrung.

​
3. Evidence

Evidence ist eine Datei, die an einen Case gehängt wird und die Behauptungen darin stützt. Angenommen werden genau zwei Arten: Bilder (JPEG, PNG, GIF, WebP) bis 5 MB und PDFs bis 20 MB — ein CAD-Screenshot oder ein eingescannter Bericht geht also, ein Video oder eine Tabellendatei nicht. Evidence wird in einem sicheren EU-gehosteten Object-Store gespeichert und per Referenz an den Case gebunden, nicht eingebettet — damit der Case-Datensatz schlank und schnell bleibt. Ab dem Tarif Team führt FTS automatisch OCR auf Bild- und PDF-Evidence aus, und du kannst den erkannten Text am Nachweis selbst lesen. Durchsuchbar ist er nicht. Eine frühere Fassung dieser Seite sagte, der extrahierte Text werde neben dem Case-Body indexiert und man könne nach einem Wort suchen, das nur auf einem Foto einer handschriftlichen Notiz stand — beides trifft nicht zu. Der Volltext-Index besteht aus genau vier Feldern (Titel, Beobachtung, Ursache, Lösung), und der Text hinter der semantischen Suche ergänzt diese vier nur um Kategorie, Schweregrad und Tags. Wer einen Fall über etwas wiederfinden will, das nur im Bild steht, schreibt es in den Fließtext des Falls.

​
4. Review-Workflow

Cases durchlaufen einen leichtgewichtigen, aber strikten Review, bevor sie zur „Wahrheit” werden:
Die fünf Namen oben sind die Werte aus enum CaseStatus. In der deutschen Oberfläche heißen sie „Entwurf”, „In Prüfung”, „Verifiziert”, „Veröffentlicht” und „Archiviert” — genau so stehen sie im Statusfilter.
  • „Entwurf” ist, wo du schreibst. Allein bist du dabei nicht: ein Entwurf ist für jedes Mitglied deiner Organisation sichtbar und über die Suche auffindbar. Eine Sichtbarkeitseinstellung je Fall gibt es nicht.
  • „In Prüfung” heißt, der Fall liegt zur Prüfung vor. Bearbeiten blockiert dieser Status nicht — kein Status tut das. Wer speichert, setzt den Fall auf „Entwurf” zurück, und er muss erneut geprüft werden.
  • „Verifiziert” heißt, dass ein zweites Augenpaar die Fakten bestätigt hat.
  • „Veröffentlicht” ist die freigegebene, kanonische Fassung. Sichtbar war der Fall auch vorher schon; was dieser Status ändert, ist die Verbindlichkeit.
  • „Archiviert” ist, wie du einen Fall außer Dienst stellst, ohne ihn zu löschen. Er verschwindet aus Liste und Suche und bleibt im Verlauf erhalten.
Jeder Statusübergang wird mit Zeitstempel und verantwortlichem User im Audit-Log festgehalten.

​
5. Taxonomy

Eine Taxonomy ist das strukturierte Vokabular, das deine Organisation zur Klassifikation von Cases nutzt. Es besteht aus genau drei Listen, und alle Workspaces der Organisation teilen sie sich:
  • Arbeitsbereichstypen — wofür ein Workspace steht (testbed, production_line, lab, field)
  • Schweregrade — wie schwerwiegend der Case ist (critical, high, medium, low)
  • Kategorien — die Art des Problems (hardware, software, process, configuration, other)
Admins bearbeiten diese drei Listen unter Einstellungen → Taxonomie-Konfiguration — das setzt zusätzlich den Tarif Team oder Enterprise voraus; im Starter-Tarif gelten die oben genannten mitgelieferten Werte.
Sie fügen Werte hinzu und entfernen sie. Umbenennen, Zusammenführen und Zurückziehen gibt es nicht. Eine frühere Fassung dieser Seite nannte vier Dimensionen — Bauteil, Fehlermode, Standort und Severity — und versprach, dass das Umbenennen eines Tags jeden Case aktualisiert, der es verwendet. Beides trifft nicht zu. Wird ein Wert aus einer Liste entfernt, ändert das nichts an Cases, die ihn bereits tragen: Der gespeicherte Wert bleibt unverändert stehen und wird lediglich nicht mehr zur Auswahl angeboten. Tags sind eine getrennte, flache Liste und lassen sich ebenfalls nicht umbenennen — ein Tag wird jeweils einem einzelnen Case hinzugefügt oder von ihm entfernt.

​
6. Rollen und Berechtigungen

FTS nutzt drei Rollen, und sie hängen an der Organisation: Rollen gelten je Organisation, nicht je Workspace: eine Person hat genau eine Rolle, und die gilt in jedem Workspace dieser Organisation. Jemand kann also nicht in einem Workspace Admin und in einem anderen nur Operator sein.

​
Wie alles zusammenpasst

Sobald du dieses mentale Modell hast, ist der Rest des Produkts nur Werkzeug, um jede dieser Dinge schneller, sauberer und sicherer zu machen.

Bereit für den ersten Walkthrough?

Spiele einen echten Fehlerbericht Schritt für Schritt durch.