// stack · schnittstelle
P&I LogaHR ist eine HR-Suite aus Wiesbaden — Abrechnung, Personalmanagement, Zeitwirtschaft und Bewerbermanagement auf einer Plattform, verbreitet vor allem dort, wo viele Personalfälle und feste Regelwerke zusammenkommen. Für eine Website zählt davon ein Ausschnitt: Wie kommen die Stellenausschreibungen auf die eigene Karriereseite — und zwar so, dass sie dort wie eigene Seiten aussehen, funktionieren und gefunden werden. siteway baut diese Strecke.
// definition
P&I LogaHR ist die HR-Software der P&I Personal & Informatik AG aus Wiesbaden. Die Wurzeln des Unternehmens reichen bis 1968 zurück, und der Name LOGA begleitet die Produktlinie seit den frühen Abrechnungssystemen — weshalb in Ausschreibungen, Stellenanzeigen und Projektunterlagen bis heute alle Schreibweisen nebeneinander auftauchen. Der Hersteller selbst nennt die Plattform aktuell P&I LogaHR und die Oberfläche P&I LOGA3.
Die Suite bündelt mehrere Bereiche auf einer Plattform: Lohn- und Gehaltsabrechnung, Personalmanagement rund um die digitale Personalakte, Zeitwirtschaft sowie Recruiting und Talent Management. Als Zielbereiche nennt der Hersteller den öffentlichen Sektor, das Gesundheits- und Sozialwesen und die Privatwirtschaft — also typischerweise Organisationen, in denen Tarifwerke, Stellenpläne und Mitbestimmung eine Rolle spielen. Das Bewerbermanagement führt der Hersteller unter der Bezeichnung P&I Bewerber3.
Für eine Website ist davon genau ein Ausschnitt relevant: das Bewerbermanagement. Dort legt die Personalabteilung Ausschreibungen an, dort läuft das Auswahlverfahren, dort liegen die Unterlagen. Die Website ist die Schauseite dieses Systems — sie zeigt die offenen Stellen und führt in den Bewerbungsweg, ohne selbst zum zweiten Datenhaushalt zu werden. Genau diese Trennung macht die Anbindung sauber: siteway behandelt LogaHR als führendes System und die Website als Anzeige.
// praxis
erst klären, dann bauen
Eine Anbindung an LogaHR beginnt anders als eine an ein Cloud-Produkt mit offener Dokumentation. Für diese Software gibt es keine frei zugängliche Entwicklerdokumentation: Was an Export, Schnittstelle und Feldern zur Verfügung steht, hängt an eurem Vertrag, an eurer Installation und häufig an einem Rechenzentrum, das den Betrieb übernimmt. Deshalb steht am Anfang keine Zeile Code, sondern eine Sichtung — gemeinsam mit dem Hersteller oder eurer HR-IT.
Vier Fragen klären dabei fast alles: Welcher Weg ist freigeschaltet, um die offenen Stellen aus dem System zu bekommen? Welche Felder liefert dieser Weg — und wie heißen sie bei euch? In welchem Takt darf abgerufen werden? Und wie ist der Bewerbungsweg vorgesehen: im Portal des Systems oder über ein eigenes Formular? Aus den Antworten entsteht ein Feld-Mapping, und erst danach wird gebaut — dasselbe Vorgehen wie bei jeder anderen Schnittstelle.
Was danach folgt, ist unabhängig vom System immer dasselbe Muster: Stellen als Daten abholen, ins CMS übersetzen, die Seiten selbst rendern. Der Grund ist nicht Geschmack, sondern Kontrolle. Nur bei eigenem Markup entscheidet siteway über strukturierte Daten, Barrierefreiheit, Ladeverhalten und URL-Struktur — also über genau die Punkte, an denen eine Karriereseite gefunden wird oder eben nicht.
Unabhängig davon, wie ein HR-System seine Wege benennt, laufen sie auf drei Muster hinaus. Sie unterscheiden sich nicht in der Qualität, sondern darin, wo die Arbeit liegt und wem das Ergebnis gehört. Das hier ist die Entscheidungshilfe, mit der wir in ein Briefing gehen — welches Muster bei euch verfügbar ist, zeigt die Sichtung.
// w-01export
Das System stellt die offenen Ausschreibungen als abrufbare Datei oder als Feed bereit, die Website holt sie in festem Takt ab. Robust, sparsam mit Rechten, unabhängig von der Verfügbarkeit der Quelle im Moment des Seitenaufrufs — und ausreichend, solange die enthaltenen Felder alles hergeben, was die Stellenseite zeigen soll.
stärke: robust · einfach
// w-02schnittstelle
Ist ein direkter Zugriff freigeschaltet, lassen sich Stellen gezielt abfragen — und je nach Freigabe auch Daten zurückgeben, etwa eine Bewerbung aus einem eigenen Formular. Der Weg trägt mehr Felder und feinere Abfragen, verlangt dafür Zugangsdaten, klare Berechtigungen und eine Abstimmung mit der HR-IT.
stärke: beide richtungen
// w-03portal
Der Stellenbereich des HR-Systems wird verlinkt oder im Rahmen der Website gezeigt. Das ist der schnellste Start, weil praktisch nichts gebaut wird. Gestaltung, Markup und Ladeverhalten kommen dann vom Anbieter — inklusive der Frage, unter welcher Adresse der Inhalt zählt. Für einen geschützten Bewerberbereich mit Login ist das oft genau richtig.
stärke: sofort startklar
Die Zuordnung fällt meist schnell. Ein Export reicht, wenn eine überschaubare Zahl Stellen mit klaren Feldern gezeigt werden soll und ein Abgleich im Minuten- oder Stundentakt genügt. Eine Schnittstelle braucht es, sobald Daten zurücklaufen sollen oder Felder gefragt sind, die im Export nicht auftauchen. Das Portal ist der richtige Griff, wenn der geschützte Bereich für Bewerberinnen und Bewerber ohnehin beim Anbieter bleibt.
Häufig ist die Kombination die beste Antwort: Stellenliste und Detailseiten aus dem Export auf der eigenen Domain, der Bewerbungsweg mit Login und Statusanzeige im System. So bleibt die Sichtbarkeit bei euch und der sensible Teil dort, wo Rollen und Fristen ohnehin greifen. Diese Aufteilung gehört an den Anfang des Konzepts, nicht ans Ende. Dieselbe Frage stellt sich bei benachbarten HR-Systemen — etwa bei rexx systems, Personio oder sopea.
// bausteine · 6 details
jedes teil mit klarem zweck
Zwischen „Stelle steht im Bewerbermanagement" und „Stelle steht auf der Website" liegen sechs Bauteile. Sie sind bei jedem Projekt gleich — was sich unterscheidet, sind die Feldbezeichnungen und der Takt.
// d-01abholung
Ein geplanter Job holt die Stellen in festem Takt und legt sie lokal ab. Kein Besucher wartet auf ein Fremdsystem, kein Seitenaufruf erzeugt einen Zugriff nach außen. Antwortet die Quelle einmal nicht, bleibt der letzte gute Stand stehen, statt dass die Karriereseite leer läuft.
zweck: tempo · ausfallsicherheit
// d-02mapping
Jedes Feld der Quelle bekommt ein Zuhause im CMS: Titel, Standort, Bereich, Anstellungsart, Beschreibung, Bewerbungsfrist, Bewerbungslink, dazu Kennziffer und Entgeltgruppe, wenn die Ausschreibung sie führt. Was fehlt, ergänzt die Redaktion daneben — etwa ein Teamfoto oder eine Ansprechperson.
zweck: felder statt textblock
// d-03liste
Die Übersicht filtert nach Standort, Bereich und Anstellungsart — mit sprechenden URLs, damit ein Filterstand teilbar bleibt. Weil die Liste aus eigenen Daten entsteht, taucht sie auch in der Website-Suche auf statt in einem abgeschotteten Rahmen.
zweck: finden statt scrollen
// d-04detailseite
Jede Stelle bekommt eine eigene, stabile und indexierbare Adresse unter deiner Domain — teilbar per Mail, verlinkbar aus Social, sauber in der Vorschau. Das Layout ist deins: dieselbe Typografie, dieselbe Navigation, derselbe Footer wie auf dem Rest der Website.
zweck: eine stelle · eine url
// d-05lebenszyklus
Verschwindet eine Stelle aus der Quelle, verschwindet sie aus der Liste. Für die Detailseite gibt es drei saubere Optionen: Ablaufdatum in die Vergangenheit, Statuscode 404 oder 410, oder das Markup entfernen. Wir wählen je Projekt eine — und leiten Besucher auf die Übersicht statt in die Sackgasse.
zweck: keine karteileichen
// d-06betrieb
Ein Abgleich, der stillschweigend scheitert, ist gefährlicher als einer, der laut abbricht. Deshalb wird jeder Lauf protokolliert, Fehler werden gemeldet, und ein leeres Ergebnis überschreibt niemals einen gefüllten Stand. Mehr dazu unter Deployment & Betrieb.
zweck: fehler fallen auf
An dieser Stelle entscheidet sich, wie sich die Karriereseite anfühlt. Der direkte Weg ist die Weiterleitung: Der Button auf der Stellenseite führt in das Bewerberportal des Systems. Upload, Pflichtfelder und Eingangsbestätigung liegen dann beim Hersteller, die Bewerbung ist ohne Umweg im Bewerbermanagement, und auf dem Webserver entstehen gar keine Bewerberdaten. Der Preis ist ein sichtbarer Wechsel — anderes Layout, mitunter ein eigener Hinweis zum Datenschutz.
Der zweite Weg ist ein eigenes Formular auf deiner Domain, das die Daten über die Schnittstelle übergibt. Die bewerbende Person bleibt durchgehend bei dir, Felder und Fehlermeldungen sind gestaltbar, die Barrierefreiheit liegt in unserer Hand — wie bei allen Formularstrecken. Dafür braucht es einen freigegebenen Übergabeweg, ein sorgfältiges Mapping und eine ehrliche Fehlerbehandlung: Was passiert, wenn die Übergabe scheitert, nachdem jemand auf „Absenden" geklickt hat?
Welcher Weg gebaut wird, hängt weniger an der Technik als an der Erwartung: Soll die Bewerbung Teil der Website sein oder Teil des HR-Systems? Bei öffentlichen Arbeitgebern kommt oft eine dritte Stimme dazu, weil Auswahlverfahren dokumentiert und nachvollziehbar bleiben müssen. Wir stellen diese Frage im Briefing — und beantworten sie gemeinsam, bevor eine Zeile Template entsteht.
// integration · 3 systeme
drei systeme · ein muster
Ein Bewerbermanagement liefert Daten, ein CMS macht daraus Seiten. Der Weg dazwischen ist systemunabhängig und sieht in jedem CMS gleich aus: Ein geplanter Job holt die Stellen in festem Takt, legt jede Ausschreibung als eigenen Inhalt im CMS an — mit einer eigenen, indexierbaren URL je Stelle — und das Frontend rendert daraus Liste, Filter und Detailseite. Aus denselben Feldern entsteht beim Rendern das JobPosting-Markup für Google for Jobs. Unterschiedlich ist nur, wie das jeweilige System Inhalte modelliert und wiederkehrende Aufgaben plant.
Im CMS liegt dabei das Datenmodell: Titel, Standort, Bereich, Anstellungsart, Beschreibung, Bewerbungsfrist und Bewerbungslink als einzelne Felder statt als Textblock — dazu Platz für das, was die Redaktion daneben ergänzt. Die Auslieferung übernimmt der Cache, sodass kein Seitenaufruf auf ein Fremdsystem wartet. Der Bewerbungsweg setzt an der Detailseite an: Der Button führt in das Portal des Systems oder in ein eigenes Formular auf deiner Domain. Weil bei LogaHR die verfügbaren Felder je Installation abweichen, wird das Datenmodell im CMS bewusst schlank gehalten und um genau die Felder ergänzt, die eure Quelle tatsächlich liefert.
// cms-01typo3
Der Weg führt über eine eigene Extension: Extbase als Unterbau, TCA für die Felddefinition, ein Scheduler-Task für den Abruf im festen Takt. Die Stellen landen als eigene Records in einem Ordner im Seitenbaum, das Site Handling erzeugt daraus die eigenen URLs, Fluid rendert Liste und Detailseite. Standort, Bereich und Anstellungsart liegen als eigene Felder, damit Filter und Sprachbäume mitlaufen. Mehr zum System unter TYPO3.
weg: eigene extension · scheduler
// cms-02wordpress
Hier entsteht ein eigenes Plugin statt Code im Theme — damit die Anbindung einen Theme-Wechsel überlebt. Ein Custom Post Type mit Meta-Feldern nimmt die Stellen auf, Taxonomien bilden Standort und Bereich ab, ein geplanter Lauf holt die Daten. Eine eigene Permalink-Struktur gibt jeder Stelle ihre Adresse, das JobPosting-Markup setzt ein Hook im <head> der Detailseite. Mehr zum System unter WordPress.
weg: eigenes plugin · custom post type
// cms-03statamic
Unter Statamic liegt ein vollständiges Laravel — der Abruf ist deshalb ein Artisan-Command im Scheduler. Ein Blueprint gibt das Datenmodell vor, die Stellen werden zu Entries in einer eigenen Collection, deren Route die eigene URL je Stelle ergibt. Antlers oder Blade rendern Liste und Detailseite, das Static Caching liefert den fertigen Stand aus. Mehr zum System unter Statamic.
weg: artisan-command · entries
// sichtbarkeit
markup entscheidet, nicht layout
Wer eine Stelle sucht, tippt einen Jobtitel bei Google ein. Damit eine Anzeige in der Job-Box darüber erscheint, verlangt Google zweierlei: Die Seite muss gecrawlt werden können, und sie muss JobPosting als strukturierte Daten enthalten. Pflichtangaben sind Titel, Beschreibung, Veröffentlichungsdatum, Arbeitgeber und Arbeitsort. Empfohlen kommen unter anderem Ablaufdatum, Anstellungsart, eine eigene Kennung und die Gehaltsangabe dazu — und gerade Letztere entscheidet mit, ob eine Anzeige in gefilterten Ergebnissen überhaupt auftaucht.
Genau darin liegt der Grund für die eigene Karriereseite: Das Markup entsteht erst im CMS. Liegen die Stellen als eigene Seiten auf deiner Domain, wird es beim Rendern aus den Feldern erzeugt, die aus dem Bewerbermanagement kommen — ein Feld, ein Attribut. Wird ein Stellenportal dagegen von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiterhin zu dieser Adresse; erfasst wird die Stelle dann dort und nicht unter deiner URL. Beides kann nebeneinander bestehen, aber nur der eigene Weg baut Sichtbarkeit auf der eigenen Domain auf.
Dazu gehört auch das Ende: Google nennt drei Wege für besetzte Stellen — Ablaufdatum in der Vergangenheit, Statuscode 404 oder 410, oder das Markup entfernen. Wie wir strukturierte Daten grundsätzlich bauen, steht unter Strukturierte Daten; was speziell für Stellenanzeigen gilt, unter Google for Jobs.
// datenschutz
so wenig wie möglich, so kurz wie möglich
Eine Bewerbung ist kein Kontaktformular. Lebenslauf, Zeugnisse, Geburtsdatum, manchmal ein Foto — das sind personenbezogene Daten der empfindlichsten Sorte, und sie werden ausgerechnet von Menschen übergeben, die dem Arbeitgeber noch nicht verbunden sind. Deshalb ist die erste Regel bei der Anbindung Datensparsamkeit: Die Website fragt nur ab, was für die Auswahl gebraucht wird, und legt nichts länger ab, als der Weitertransport dauert.
Technisch heißt das: Übertragung ausschließlich verschlüsselt, Zugangsdaten in der Serverkonfiguration statt im Repository, Anhänge direkt weiterreichen statt in einem Upload-Ordner sammeln, Zugriffe protokollieren. Führendes System bleibt LogaHR — dort greifen Rollen, Protokolle und die Löschfristen, die das Personalwesen ohnehin einhalten muss. Für sein HR-Cloud-Rechenzentrum nennt der Hersteller unter anderem ISO 27001, BSI C5 Typ 2 und ISAE 3402 Typ 2; diese Angaben ersetzen die eigene Prüfung nicht, geben ihr aber eine Grundlage.
Rechtlich gehört ein Auftragsverarbeitungsvertrag dazu, ebenso ein Datenschutzhinweis an genau der Stelle, an der die Daten erhoben werden — kurz, verständlich und ohne vorangekreuzte Einwilligung. Bei Behörden, Kommunen und anderen öffentlichen Trägern kommen Landesdatenschutzgesetze, ein behördlicher Datenschutzbeauftragter und interne Freigabeverfahren dazu, die früh in den Zeitplan gehören. Wie siteway das grundsätzlich hält, steht unter Sicherheit & Datenschutz.
Ein Bewerbungsformular ist die engste Stelle der ganzen Strecke: Wer hier scheitert, bewirbt sich nicht. Bei öffentlichen Stellen kommt hinzu, dass Barrierefreiheit dort nicht nur guter Stil, sondern Auflage ist. Deshalb bekommt jedes Feld ein sichtbares, dauerhaft verknüpftes Label statt eines Platzhalters, der beim Tippen verschwindet. Pflichtfelder sind im Text benannt, nicht nur durch ein Sternchen. Fehler stehen am Feld, in Worten, und der Fokus springt dorthin — nicht in eine rote Zeile ganz oben, die eine Screenreader-Nutzerin nie erreicht.
Der Datei-Upload nennt erlaubte Formate und Größen, bevor jemand die falsche Datei wählt, und bleibt per Tastatur bedienbar. Nach dem Absenden gibt es eine Rückmeldung, die auch angesagt wird. Das gilt für das eigene Formular ebenso wie für die Entscheidung, in das Portal des Herstellers weiterzuleiten — dann prüfen wir vorher, wie es sich dort verhält, und halten das Ergebnis fest. Die Grundlagen dazu stehen unter Barrierefreiheit.
// faq
P&I LogaHR ist die HR-Software der P&I Personal & Informatik AG mit Sitz in Wiesbaden. Die Wurzeln des Unternehmens reichen bis 1968 zurück, der Produktname LOGA begleitet die Software seit den frühen Abrechnungssystemen; heute nennt der Hersteller die Plattform P&I LogaHR und die Oberfläche P&I LOGA3. Die Suite bündelt Lohn- und Gehaltsabrechnung, Personalmanagement mit digitaler Personalakte, Zeitwirtschaft sowie Recruiting und Talent Management. Der Hersteller nennt als Zielbereiche den öffentlichen Sektor, das Gesundheits- und Sozialwesen sowie die Privatwirtschaft. Für eine Website zählt davon genau ein Ausschnitt: das Bewerbermanagement, das der Hersteller als P&I Bewerber3 führt.
Über einen Weg, der die Ausschreibungen als Daten aus dem System herausträgt: einen Export beziehungsweise Feed der offenen Stellen oder eine Schnittstelle, über die sich dieselben Daten abfragen lassen. Die Website holt diese Daten in festem Takt ab, ordnet jedes Feld einem Feld im CMS zu und legt jede Stelle als eigenen Inhalt mit eigener URL an. Welcher Weg in eurer Installation tatsächlich freigeschaltet ist, klärt siteway vorab mit dem Hersteller oder eurer HR-IT — bei dieser Software ist das der erste Schritt und nicht der letzte, weil es dazu keine frei zugängliche Entwicklerdokumentation gibt.
Öffentlich einsehbar ist sie nicht. Anders als bei Systemen mit offener API-Dokumentation liegen die Angaben zu Export, Schnittstelle, Feldern und Freischaltung beim Hersteller und beim betreuenden Rechenzentrum. Für ein Projekt heißt das: keine Annahmen, sondern eine Sichtung. siteway fragt vor dem Bauen ab, welcher Weg vertraglich und technisch freigeschaltet ist, welche Felder er liefert, in welchem Takt er aktualisiert wird und wie der Bewerbungsweg vorgesehen ist. Aus diesen Antworten entsteht das Feld-Mapping — und erst danach entsteht Code. Was auf dieser Seite steht, beschreibt deshalb bewusst das Muster und nicht erfundene Endpunkte.
Ja. In allen drei Systemen trägt derselbe Aufbau: Ein geplanter Job holt die Stellen ab, legt jede Ausschreibung als eigenen Inhalt im CMS an, und das Frontend rendert Liste, Filter und Detailseite — jede Stelle mit einer eigenen, indexierbaren URL auf deiner Domain. In TYPO3 baut siteway dafür eine eigene Extension mit Scheduler-Task, eigenen Datensätzen und Fluid-Templates. In WordPress ein eigenes Plugin mit einem Custom Post Type und Taxonomien für Standort und Bereich. In Statamic ein Artisan-Kommando im Scheduler, das Entries in eine Collection schreibt. Weil die Feldbezeichnungen je Installation abweichen, wird die Abholung als schlanker eigener Code gebaut und das Mapping vorab abgestimmt. Das JobPosting-Markup entsteht anschließend in allen drei Systemen aus denselben Feldern.
Google zeigt eine Stelle in der Job-Box nur, wenn die Seite gecrawlt werden kann und JobPosting-Markup als strukturierte Daten enthält. Pflicht sind Titel, Beschreibung, Veröffentlichungsdatum, Arbeitgeber und Arbeitsort; empfohlen sind unter anderem Ablaufdatum, Anstellungsart und Gehalt. Genau dieses Markup entsteht, wenn die Stellen als eigene Seiten auf deiner Domain liegen — siteway erzeugt es beim Rendern aus den Feldern, die aus dem Bewerbermanagement kommen. Wird ein Stellenportal dagegen von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiter zu dieser Adresse und wird dort erfasst, nicht unter deiner URL.
Beides trägt. Der direkte Weg ist die Weiterleitung: Der Button auf der Stellenseite führt in das Bewerberportal des Systems, dort läuft der Upload, und die Bewerbung liegt ohne Umweg im Bewerbermanagement — auf dem Webserver entstehen dabei gar keine Bewerberdaten. Der Preis ist ein sichtbarer Wechsel in ein anderes Layout. Der zweite Weg ist ein eigenes Formular auf deiner Domain, das die Daten über die Schnittstelle übergibt: durchgängig im Design deiner Website, mit voller Kontrolle über Pflichtfelder, Fehlermeldungen und Barrierefreiheit, dafür mit mehr Aufwand und einer Abhängigkeit von den freigegebenen Übergabewegen. siteway klärt das vor dem Bauen, weil daran der ganze Bewerbungsweg hängt.
Fällt eine Stelle aus der Quelle, verschwindet sie beim nächsten Abgleich aus der Liste. Für die Detailseite nennt Google drei saubere Wege: das Ablaufdatum in die Vergangenheit setzen, die Seite mit Statuscode 404 oder 410 beantworten oder das JobPosting-Markup entfernen. Welcher Weg gewählt wird, legt siteway je Projekt fest — und leitet abgelaufene Stellen dorthin, wo es weitergeht: auf die Karriereübersicht statt in eine Sackgasse. Gerade bei öffentlichen Ausschreibungen lohnt der Blick auf die Frist, weil Bewerbungsschluss und Sichtbarkeit dort oft aneinanderhängen.
Für alle Arbeitgeber gilt die DSGVO, und Bewerbungsunterlagen zählen zu den empfindlichsten Daten, die eine Website berührt. Bei Behörden, Kommunen und anderen öffentlichen Trägern kommen zusätzliche Vorgaben dazu: Landesdatenschutzgesetze, behördliche Datenschutzbeauftragte, Vorgaben zur Barrierefreiheit aus dem Behindertengleichstellungsrecht und interne Freigabeverfahren, die früh eingeplant gehören. Praktisch heißt das: Datensparsamkeit am Formular, verschlüsselte Übertragung, Anhänge weiterreichen statt lagern, Zugangsdaten in der Serverkonfiguration statt im Repository, Löschfristen im führenden System und ein Auftragsverarbeitungsvertrag vor dem Go-live. Der Hersteller nennt für sein HR-Cloud-Rechenzentrum unter anderem ISO 27001, BSI C5 Typ 2 und ISAE 3402 Typ 2 — das ersetzt die eigene Prüfung nicht, gibt ihr aber eine Grundlage.
// womit das zusammenhängt
komponente, leistung & nachbarn
// komponente · buchen
Der Baustein, der auf deiner Website entsteht: Stellenliste, Detailseiten, Bewerbungsformular und Karriere-Übersicht. Hier wird gebucht.
zur komponente →
// leistung · buchen
Die Leistung hinter dieser Seite: Sichtung, Feld-Mapping, Entwicklung, Test und Monitoring — für LogaHR wie für jedes andere Fremdsystem.
zur leistung →
// stack · sichtbarkeit
Was eine Stellenanzeige mitbringen muss, um in der Job-Box zu erscheinen — Pflichtfelder, Ablaufdatum und die häufigsten Stolpersteine.
zur technik →
// stack · schwester
Dieselbe Frage, anderes System: wie Stellen aus dem rexx-Bewerbermanagement auf die eigene Karriereseite kommen.
zur technik →
// stack · schwester
Der Gegenpol zu einer Suite ohne offene Doku: wie Stellen aus Personio auf die Karriereseite kommen — und wo sich die Wege unterscheiden.
zur technik →
// stack · schutz
Verschlüsselung, Header, Datensparsamkeit und der Umgang mit Zugangsdaten — die Regeln, nach denen jede Anbindung gebaut wird.
zur technik →
// Stellen aus P&I LogaHR auf deiner eigenen Karriereseite?
Anbindung anfragen