Interview-Planer

A1Architektur: Einordnung in die Plattform

Interview-Planer is a first-class module of the Interviewing suite inside the authenticated Expertini ATS workspace. Die Plattform ist bewusst servergerendert: Jede Ansicht wird vom Anwendungsserver vorbereitet und als vollständiges HTML ausgeliefert, ohne clientseitiges Framework, ohne CDN-Skripte von Drittanbietern und ohne Build-Pipeline zwischen den Daten und der Seite. Was dargestellt wird, ist genau das, was der Server berechnet hat – die Eigenschaft, die die Benutzeroberfläche prüfbar macht.

Die gesamte Persistenz basiert auf einem einheitlichen, suchnativen Dokumentenspeicher; jede Abfrage enthält die Kennung der Organisation als obligatorischen Filter auf der untersten Abfrageebene. Die Mandantentrennung ist somit strukturell – eine Eigenschaft des Aufbaus jeder Anfrage – und nicht bloß eine Richtlinie, die darauf vertraut, dass der Anwendungscode die Prüfung durchführt.

Availability is governed by the platform's tool registry: this tool is registered from the Trial plan, and access is enforced server-side by the registry gate on every request — never by hiding a button. Plans also carry a monthly distinct-tool quota (3 / 5 / 15 / 30 / 45 across Trial→Business, unlimited on Enterprise), counted at the same chokepoint. The pricing page states both honestly: what is available, and how much of it the month includes.

A2Datenmodell und Abhängigkeitszuordnung

In production the tool reads and writes pipeline applications (ats_applications), job requisitions (ats_jobs), interview records (ats_interviews). Documents are plain, explicitly-mapped fields — mappings are provisioned ahead of first write, so term filters and aggregations behave deterministically instead of depending on inferred types.

Jedes einzelne Öffnen wird im Tool-Aktivitätsspeicher protokolliert – und dieses Protokoll, kein paralleles Analysesystem, wird im Bereich „Berichte“ aggregiert. Die Nutzungszahlen, die Sie sehen, sind die Zahlen, die die Plattform tatsächlich aufgezeichnet hat.

Alles, was den Anfragepfad verlässt — Benachrichtigungsverteilung, Webhook-Zustellung, Aktivitätsprotokollierung, E-Mails —, läuft in Fire-and-Forget-Hintergrund-Threads. Ein langsamer externer Endpunkt kann niemals die Benutzeroberfläche blockieren, und eine fehlgeschlagene Nebenwirkung wird protokolliert, anstatt stillschweigend wiederholt zu werden und zu Inkonsistenzen zu führen.

A3Operative Überlegungen

Einstellungen auf Organisationsebene, destruktive Aktionen und Verbindungen sind Inhaber- und Administratorrollen vorbehalten; Recruiter bedienen das Tool bei den Datensätzen, die sie einsehen können. Rollenänderungen greifen bei der nächsten Anfrage – die Durchsetzung erfolgt auf Routing-Ebene, nicht im Menü.

Fehler werden offengelegt, nicht verschluckt: Die serverseitige Validierung gibt das genaue Feld und den Grund zurück, Anbieterfehler werden bei Integrationen wortgetreu zitiert und jeder Schreibvorgang wird entweder bestätigt oder gemeldet. Exporte werden auf Anfrage neu generiert und nicht zwischengespeichert – ein heruntergeladener Bericht spiegelt den Datenbestand zum Zeitpunkt der Anfrage wider, nicht den Snapshot der letzten Nacht.

Alle erfassten Daten gehören Ihnen: CSV-Exporte und die Datenexport-App decken dieselben Speicher ab, auf die auch das Produkt selbst zugreift. Der Ausstieg steht Ihnen genauso offen wie der Einstieg – aus Prinzip, nicht aus Zugeständnis.

A4Interaction contract

Die Benutzeroberfläche folgt der Plattform-Konvention „Suchen und Auswählen“: Jedes Feld, das einen realen Datensatz benennt – einen Kandidaten, Kunden oder eine Stelle –, ist ein Live-Suchfeld über Echtzeitdaten und niemals eine Freitexteingabe, wodurch Aktivitätenprotokolle und Deduplizierung verlässlich bleiben. Statische Optionen sind Auswahllisten mit Sofortfilter statt nativer Dropdowns, und Statuswechsel geben klares Feedback: Serverbestätigungen erscheinen als Toast-Benachrichtigungen, Validierungsfehler benennen das genaue Feld, und nichts wird als erledigt angezeigt, was der Server nicht bestätigt hat.

Das Wireframe und der Ablauf unten dokumentieren den strukturellen Aufbau der Oberfläche – welche Bereiche vorhanden sind, in welcher Reihenfolge die Zustände auftreten und was an den Rändern geschieht – anstatt einzelner Pixel. Das Layout basiert auf nativem CSS-Grid und Flexbox und passt sich von breiten Desktop-Bildschirmen bis hin zu einer einspaltigen Ansicht ohne separate mobile Layouts an.