Es ist sicherlich möglich, einen Import selbst durchzuführen, je nachdem, welches technische Verständnis beim Kunden zur Verfügung steht und wie geduldig er dabei vorgeht.

Dies würde so funktionieren, dass ein interner Mitarbeiter ein Skript schreibt, welches Daten aus der vorhandenen Datenbank nimmt, in ein Teamtailor-kompatibles Format umwandelt und es dann an uns senden kann. Dies kann entweder geschehen, indem die Daten aus der bestehenden Datenbank des Kunden über die API oder durch ein Dokument exportiert werden.

Im Grunde ist das Einzige das zählt, dass Personen daran arbeiten, die die Daten und API verstehen.

Das ist eine schwierigere Frage – es gibt viele Vor- und Nachteile dabei. Normalerweise wäre es eher für größere Unternehmen ratsam, die über mehr Ressourcen verfügen, um dies zu tun, und auch einen größeren Bedarf an einer schnelleren Lösung haben.

Vorteile

Nachteile

Teamtailor hat ein relationales Datenmodell, was bedeutet, dass Objekte Attribute haben können, die einzigartig für sie sind, und Beziehungen zu anderen Objekten, die es nicht sind. Diese Beziehungen sind entscheidend, um zu verstehen, wie Teamtailor funktioniert.

Attribute enthalten Daten, die einzigartig für diese spezifische Stellenbewerbung sind – wann sie erstellt wurde, ob die den Status "rekrutiert" hat, und so weiter.

Beziehungen enthalten Daten, die nicht einzigartig für diese Jobbewerbung sind, sondern auch unabhängig von ihr existieren. Beispielsweise hat jede Bewerbung eine Kandidat- und Stellen-Beziehung.

Diese werden genutzt, um besser zu verstehen, wer diese Bewerbung erstellt hat und für welche Position sie erstellt wurde.

Dies kann hilfreich sein weil, wenn es Änderungen am Kandidaten oder der Stelle gibt, die Bewerbung immer noch funktionieren wird, da sie nur einen Link dazu hat. Sie ist nicht direkt betroffen von Änderungen an den andern beiden. Dies bedeutet aber auch, dass das Erstellen von bestimmten Objekten in Teamtailor, mehr als einen Request erfordern kann.

Meistens werden Importe durchgeführt, um Kandidaten zu importieren, daher ist es wichtig zu verstehen, wie das Kandidatenobjekt funktioniert und welche Daten als Attribute des Objekts oder als Beziehungen hinzugefügt werden können.

Wie bereits erwähnt, wird ein Kandidatenobjekt eine Beziehung zu einer Bewerbung haben, wenn es zuvor eine Bewerbung gegeben hat, aber es gibt noch viele weitere solcher Beziehungen. Immerhin ist das Kandidatenobjekt das wichtigste Objekt in der Plattform.

Attribute

Die grundlegendsten Kandidatendaten sind hier zu finden – am wichtigsten sind der Name, die Kontaktinformationen, Einwilligungsdaten und andere Informationen, die dort aufbewahrt werden sollen.

Einige andere Daten können hier allerdings nicht gefunden werden - zum Beispiel gibt es kein Feld für 'Geschlecht' oder 'Alter'. Das liegt daran, dass Teamtailor mit einem open-ended Datenmodell arbeitet. Die Grundlagen liegen hier in den Attributen, aber zusätzliche Daten müssen entweder als benutzerdefinierte Felder oder Antworten hinzugefügt werden.

Beziehungen

Wie du anhand dieser Tabelle erkennen kannst, kann der Kandidat viele verschiedene Beziehungen haben.

Fragen und Antworten enthalten Daten darüber, welche Fragen der Bewerber beantwortet hat und welche Antworten gegeben wurden. Beide existieren als einzelne Objekte außerhalb des Bewerbers.

Benutzerdefinierte Feldwerte enthalten Antworten zu allen zuvor eingerichteten benutzerdefinierten Feldern. Zum Beispiel, wenn es ein benutzerdefiniertes Feld namens 'parent' gibt, dann wird der Wert des Bewerbers 'Yes' oder 'No' sagen. Das benutzerdefinierte Feld wird genauso verwendet, aber der Wert wird einzigartig für den Kandidaten sein. Der benutzerdefinierte Feldwert (Ja oder Nein) wird sich auf den Kandidaten und das benutzerdefinierte Feld (Geschlecht) beziehen.

Notizen (Kommentare) können beliebige Freitextinformationen enthalten, die der Recruiter eingetragen hat und können auch über die API hinzugefügt werden. Das kann auch Informationen enthalten, die sonst nirgends passen, zum Beispiel ein Lebenslauf-Transkript.

Activities enthalten Informationen zu jeder Aktion, die in Verbindung mit dem Kandidaten durchgeführt wurde.

Uploads enthalten alle zusätzlichen Dokumente, die der Bewerber hochgeladen hat.

Partner results enthalten alle Daten, die wir von anderen Integrationen erhalten, die ihr möglicherweise verwendet, zum Beispiel Testergebnisse von Assessment Tests.

Department, role, regions und locations enthalten verschiedene Daten, wohin der Bewerber sich bewirbt - diese werden automatisch von jedem Job, auf den sie sich beworben haben, übernommen und sind nicht direkt mit dem Standort des Bewerbers verbunden.

Die öffentliche API von Teamtailor ist entsprechend der JSON:API-Spezifikation konzipiert. Das bedeutet, dass wir hauptsächlich JSON nutzen, wenn wir über die API kommunizieren. Die Dokumentation enthält bei Bedarf Beispiele und eine hilfreiche Bibliothek, die auch in Postman importiert werden kann.

Anzeigen der Daten

Wie bereits erwähnt, hat Teamtailor ein relationales Datenmodell, was bedeutet, dass viele der Objekte in Relation zueinander stehen, einschließlich Bewerber und ihrer benutzerdefinierten Feldwerte und Antworten. Da pro Request nur ein neues Objekt erstellt werden kann, erfordert dies eine bestimmte Anzahl von Anfragen für jeden Kandidaten.

Um dies zu vereinfachen, ist es möglich, einige dieser Beziehungen in der Antwort zu "öffnen", indem ein Include-Parameter hinzugefügt wird. Zum Beispiel, wenn du wissen möchtest, was die benutzerdefinierten Feldwerte für einen Kandidaten sind, kannst du in der Anfrage ?include=custom-field-values hinzufügen, was unter den Daten einen zusätzlichen Abschnitt namens included hinzufügt, der alle Daten zu den einzelnen benutzerdefinierten Feldwerten enthält, die unter dieser Beziehung gefunden wurden.

Das bedeutet auch, dass für jeden benutzerdefinierten Feldwert, jede Antwort oder jede Notiz (Kommentar), die zum Kandidaten hinzugefügt wird, eine separate Anfrage durchgeführt werden müsste.

Rate Limit

Das Limit beträgt 50 Anfragen pro 10 Sekunden, somit muss das Skript abkühlen, wenn diese Grenze erreicht wird, oder die Anfragen sollten so verteilt werden, dass diese Grenze nicht erreicht wird. Normalerweise ist es eine gute Idee, jeweils 300 ms Verzögerung zwischen den Anfragen hinzuzufügen, um zu verhindern, dass das rate Limit erreicht wird.

Hier ist der Ablauf für einen grundlegenden benutzerdefinierten Import:

Sobald der Upload abgeschlossen ist, kannst du die Informationen auf der Plattform überprüfen, indem du die Anzahl der Kandidaten kontrollierst und ob sie die gewünschten Daten haben.

Solltest du auf Probleme wie Fehlermeldungen stoßen, oder etwas nicht so funktioniert, wie es sollte, kannst du unseren Support kontaktieren, indem du auf das Chat-Feld in der Plattform klickst oder eine E-Mail an support@teamtailor.com sendest

Wenn du Hilfe bei allgemeineren Fragen benötigst, um z. B. ein besseres Verständnis des Prozesses oder der Datenstruktur zu bekommen, wende dich an unsere Kontaktperson im Sales Team oder an euren CSM, und sie werden dich mit jemandem in Kontakt bringen, der damit helfen kann.