Det är möjligt att göra en import själv, beroende på kundens tekniska förståelse och tålamod att arbeta igenom processen.

Detta skulle fungera genom att någon internt skriver ett skript som hämtar information från deras befintliga databas, omvandlar det till ett format som Teamtailor kan hantera, och sedan skickar det till oss. Detta kan göras antingen genom att ta data från klientens befintliga databas genom API eller genom ett dokument.

Till sist är det enda som spelar roll att ni har personer som kan förstå data och API:er.

Denna metod har både för- och nackdelar som du bör beakta. Generellt rekommenderas det här främst för större företag som har dedikerade resurser för detta och ett större behov av en snabbare lösning.

Fördelar

Nackdelar

Teamtailor har en relationell datamodell, vilket innebär att objekt kan ha attribut som är unika för dem och relationer till andra objekt som inte är det. Dessa relationer är avgörande för att förstå hur Teamtailor fungerar.

Attribut innehåller data som är unik för just den här specifika jobbansökan, till exempel när den skapades eller om den är sourcad.

Relationer innehåller data som inte är unik för denna jobbansökan men existerar utanför den. Till exempel har varje jobbansökan en relation till kandidat och jobb.

Dessa används för att bättre förstå vem som har fyllt i denna jobbansökan och vilken position den har skapats för.

Detta är hjälpsamt eftersom om det finns ändringar i Kandidaten eller Jobbet kommer jobbansökan fortfarande fungera eftersom den bara har en länk till det. Den påverkas inte direkt av ändringarna i de andra två. Dock innebär detta också att skapa vissa objekt inom Teamtailor kan kräva mer än en förfrågan.

Majoriteten av tiden görs importer för att importera kandidater och därför är det viktigt att förstå hur kandidatobjektet fungerar och vilka data som kan läggas till som attribut till objektet eller som relationer.

Som tidigare nämnts kommer ett kandidatobjekt att ha en relation till en jobbansökan om det har skett en ansökan tidigare, men det finns många fler sådana relationer. Trots allt är kandidatobjektet det viktigaste på plattformen.

Attribut

Den mest grundläggande kandidatdatan finns här - mestadels är det namn, kontaktinformation, samtyckesdata och annan sådan information som du kanske vill behålla där.

Ni kan dock märka att viss annan data inte finns här - till exempel finns det inte ett fält för 'kön' eller 'ålder'. Det är för att Teamtailor verkar med en öppen datastruktur i åtanke. Grunden finns här i attributen, men ytterligare data måste läggas till antingen som Anpassade fält eller Svar.

Relationer

Som ni kan se från denna tabell kan Kandidaten ha många olika relationer.

Frågor och svar innehåller data om vilka frågor kandidaten har svarat på och vilka svar som lämnats. Båda dessa finns som individuella objekt utanför kandidaten.

Anpassade fältvärden innehåller svar på alla anpassade fält som tidigare ställts in. Till exempel, om det finns ett anpassat fält som kallas 'parent', kommer värdet för kandidaten att säga 'ja' eller 'nej'. Det anpassade fältet kommer att användas på samma sätt, men värdet kommer att vara unikt för kandidaten. Värdet för det anpassade fältet (ja eller nej) kommer att relateras till kandidaten och det anpassade fältet (kön).

Anteckningar (kommentarer) kan innehålla all fri textinformation som rekryteraren har angett och kan också läggas till via API. Detta kan också innehålla information som inte passar någon annanstans, till exempel ett CV-transkript.

Aktiviteter innehåller information om varje åtgärd som har gjorts på kandidaten.

Uppladdningar innehåller alla ytterligare dokument som kandidaten har laddat upp.

Partnerresultat innehåller all data vi mottagit från andra integrationer som du kan använda, till exempel testresultat.

Avdelning, roll, regioner och platser innehåller olika data om var kandidaten ansöker – dessa är automatiskt ärvda från jobben de sökt till och är inte direkt kopplade till kandidatens plats.

Teamtailors offentliga API är utformat i enlighet med JSON:API-specifikationen. Detta innebär att vi främst använder JSON vid kommunikation genom API:et. Dokumentationen innehåller exempel om det behövs och ett användbart bibliotek som också kan importeras till din Postman.

Visa data

Som tidigare förklarats har Teamtailor en relationell datamodell, vilket innebär att många av objekten existerar i relation till varandra, inklusive kandidater och deras anpassade fältvärden och svar. Eftersom endast ett nytt objekt kan skapas per förfrågan krävs ett visst antal förfrågningar att göras för varje kandidat.

För att göra det enklare går det att "öppna" vissa av dessa relationer i svaret genom att lägga till en include-parameter. Till exempel, om du vill veta vilka anpassade fältvärden en kandidat har, kan du i förfrågan lägga till ?include=custom-field-values, vilket lägger till en extra sektion under datan som kallas included, där all data om de individuella anpassade fältvärdena under den relationen finns.

Detta betyder även att varje anpassat fältvärde, svar eller anteckning (kommentar) som kommer att läggas till kandidaten måste läggas till som en separat begäran.

Förfrågningsgräns

Förfrågningsgränsen är 50 förfrågningar per 10 sekunder, så skriptet behöver vila när detta nås eller förfrågningarna bör vara utspridda så att de aldrig når denna gräns. Normalt sett är det bra att lägga till en 300 ms fördröjning mellan varje förfrågan för att förhindra att förfrågningsgränsen nås.

Här är en process för en grundläggande anpassad import:

När uppladdningen är klar kan du kontrollera informationen på plattformen genom att se efter antalet kandidater och om de har de önskade uppgifterna.

Om du stöter på problem som felmeddelanden eller om något helt enkelt inte fungerar som det ska kan du kontakta vår support via chatt eller på support@teamtailor.com

Behöver du hjälp med bredare frågor, som att förstå processen bättre eller datamodellen, kontakta din säljare eller CSM så kopplar de dig till någon som kan hjälpa dig.