Product Requirements · F-100 · Vacancy-Application-Form

⚠ Superseded am 2026-05-29. Dieses PRD beschreibt den Pfad-C+-Stand (Email-Inbox-Bridge). Mit der Gewährung des Personio-Multiposting-Scopes (P2503-191) wurde die Architektur auf Pfad A (direkter API-POST) umgestellt. Aktueller Stand: 2026-05-29-vacancy-application-personio-api-post-prd.html (parallel zu ADR-0047→0050).

Vacancy-Application-Form — Drupal-natives Bewerbungsformular mit Personio-Inbox-Bridge

TL;DR — Karriere-Interessent:innen sollen sich ohne Medienbruch direkt aus einer SOLCOM-Stellenausschreibung bewerben können. Die Lösung ist eine Drupal-Webform unter einer Sub-Route pro Stelle, die Submissions via Email an die Personio-Inbox des SOLCOM-Tenants schickt und per Personio-Webhook deterministisch bestätigt. Architektur ist auf Pfad C+ (Email-Inbox-Import + Webhook-ACK) fixiert; der zunächst gewünschte direkte HTTP-POST gegen die Personio Recruiting API ist mit SOLCOMs Standard-Recruiting-Credentials nicht erreichbar (Multiposting-Partner-Scope-Gate, 17 Live-Probes durchgeführt). Bei Versand-Failure hält eine DLQ-Admin-Oberfläche HR-seitige Recovery vor.

superseded target-release 2026-07-08 (MVP go-live) P2503-90

Problem Statement

SOLCOM betreibt heute Stellenausschreibungen auf karriere.solcom.de — einer Personio-Hosted-Page unter solcom-gmbh.jobs.personio.de. Karriere-Interessent:innen, die über die Drupal-Site auf eine Vacancy-Detailseite kommen (/karriere/<slug>), werden beim Klick auf den Apply-CTA zur Personio-Hosted-Page redirected. Das hat drei Auswirkungen:

Medienbruch: Bewerber:innen verlassen die SOLCOM-Brand-Umgebung und landen in einem visuell und URL-strukturell fremden Tool. Drop-Off im Apply-Flow ist höher als bei seitennativen Formularen.
Brand-Konsistenz: Die Personio-Hosted-Page trägt SOLCOM-Logo, aber nicht das volle byte_theme-Branding (Lime-Akzent, Montserrat-Headlines, ScalaSans-Body, Sticky-Apply-Bar-Pattern).
Tracking-Bruch: Analytics, Cookies und Consent-Layer der Drupal-Site werden auf der Personio-Page nicht fortgeführt.

Aus Sicht der Bewerber:in ist der einfache Wunsch: „Ich klicke auf ‘Jetzt bewerben’, fülle ein Formular aus, lade meinen CV hoch, klicke auf Submit, und bekomme eine Bestätigung. Ich möchte nicht in ein anderes Tool wechseln und mich nicht erklären müssen, warum die Bewerbungsseite anders aussieht als die Stellenseite, von der ich komme.“

Aus Sicht von HR ist der einfache Wunsch: „Jede Bewerbung muss zuverlässig im Personio-Recruiting-Backend ankommen. Wenn etwas schiefgeht, müssen wir das sehen und manuell nachholen können, ohne dass die Bewerbung verloren geht.“

Solution

Drupal bekommt eine native Bewerbungsseite pro Stelle unter /karriere/<slug>/bewerben. Die Seite rendert einen Stellenkontext-Header und eine geteilte Webform-Entity vacancy_application, die die Felder der heutigen Personio-Hosted-Form 1:1 spiegelt. Vacancy-Kontext (Personio-Job-ID, Stellentitel, Vacancy-Node-ID) wird per Route-Parameter aufgelöst und als Hidden-Fields in die Form injiziert. Submissions werden in eine Drupal-Queue geschoben; ein QueueWorker baut daraus eine strukturierte SMTP-Mail mit den Bewerbungs-Files als Attachments und versendet sie an die Personio-Inbox des SOLCOM-Tenants. Personio importiert die Mail, legt die Application im Recruiting-Backend an und schickt ihren üblichen Webhook application.created zurück an Drupal — das ist der deterministische ACK.

1 · Drupal-Webform sammelt Bewerbung Sub-Route + Vacancy-Context-Injection

Vacancy-Detail-Seite verlinkt mit Apply-CTA auf /karriere/<slug>/bewerben. Die Sub-Route ist an die existierende pathauto-Konvention /karriere/[node:title] angelehnt. Beim Render wird die Vacancy-Node geladen und Personio-Job-ID, Stellentitel und Node-ID als Hidden-Fields in die Webform injiziert. Die Form übernimmt Layout und Feld-Inventur 1:1 vom Personio-Hosted-Apply-Pattern (CV-Upload als Pflichtfeld, Anschreiben optional, Datenschutz-Checkbox, Honeypot).

2 · Submit-Handler speichert Submission und queued den Versand private://applications/<uuid>/ + solcom_personio_application_queue

Submit-Handler speichert die Submission inklusive Files tempär in einem privaten Dateisystem-Pfad und enqueued ein Queue-Item mit Referenz auf die Submission-ID. Pipe-Through ist durch die Queue-Entscheidung explizit nicht möglich — der Worker ist zeitlich vom Submit entkoppelt, also brauchen wir persistente Files zwischen Submit und Worker-Run.

3 · QueueWorker baut SMTP-Mail und schickt an Personio-Inbox cron / drush queue:run, Tracking-Hash im Subject

Der Worker lädt die Submission und ihre Files, ruft den PersonioMailBuilder (deep module), der einen strukturierten Key-Value-Text-Body, die Files als Attachments und ein Subject mit Tracking-Hash erzeugt: Bewerbung: <Stellentitel> (Personio-Job-ID <id>) · <Bewerbername> · trace:<hash>. Der MailManager schickt die Mail an die im Drupal-State hinterlegte Personio-Inbox-Adresse. Bei Versand-Failure zählt der Worker einen Custom-Retry-Counter hoch (max 5 Versuche, Backoff 1 min/5 min/15 min/1 h/6 h).

4 · Personio importiert Mail in den Recruiting-Posteingang Personio Inbox-Import (offiziell unterstützter Pfad)

Personio jedem Tenant eine eingehende Mail-Adresse mit Auto-Parsing der eingehenden Bewerbungs-Mails (Subject + Body → Application-Felder, Attachments → CV+Dokumente). Die SOLCOM-Personio-Admin muss diese Inbox einmalig konfigurieren und sicherstellen, dass das Mail-Parsing die strukturierten Felder erkennt. Bewerber:in bekommt anschließend die übliche Personio-Bestätigungsmail.

5 · Personio-Webhook signalisiert ACK an Drupal application.created → /personio/webhook/application-created

Personio feuert nach erfolgreichem Mail-Import den Webhook application.created mit der neu erzeugten Application-ID im Payload. Drupal validiert die HMAC-Signatur gegen ein Shared-Secret, matcht via Tracking-Hash oder Bewerber-Email auf die ursprüngliche Submission und setzt den Submission-Status auf acked. Personio-Application-ID wird in Submission-Meta gespeichert.

6 · Conditional-Retention purgt nur bei ACK Files + PII raus, sonst persistent als HR-Recovery-Layer

Bei eingegangenem ACK werden Submission-PII-Felder und Files aus Drupal entfernt (DSGVO-minimal). Bleibt der ACK nach 24 h aus, läuft ein Cron-Job, der HR via Mail informiert. Bei DLQ-Erschöpfung (alle 5 Retry-Versuche fehlgeschlagen) bekommt HR ebenfalls Mail mit Submission-Details und Files-Pfad; die Submission und ihre Files bleiben dann persistent in Drupal als HR-Recovery-Layer.

★

Pfad A (direkter HTTP-POST gegen POST /v1/recruiting/applications) bleibt als Future-Refactor-Option offen, falls Personio nach Klärung mit dem Account-Manager den Multiposting-Partner-Scope für SOLCOM aktiviert. Der QueueWorker-Body wäre dann ein 1-PR-Refactor von SMTP auf HTTP — die Webform-Architektur, Sub-Route, File-Storage und Queue-Schale bleiben unverändert.

User Stories

User-Stories nach Persona gruppiert. Stakeholder-Outcome-Personas (Karriere-Interessent:in, HR-Stakeholder:in, Redakteur:in / PO) führen die Liste; Tech-Constraint-Personas (Site-Builder, Entwickler:in) wandern in die Implementation Decisions, weil ihre Bedürfnisse keine Stakeholder-Outcomes sondern Architektur-Constraints sind.

Karriere-Interessent:in

Als Karriere-Interessent:in möchte ich von einer SOLCOM-Stellenausschreibung direkt zum Bewerbungsformular gelangen, damit der Bewerbungsprozess einfach und ohne Medienbruch abläuft.
Als Karriere-Interessent:in möchte ich auf der Bewerbungsseite den Stellentitel sehen, damit ich sicher bin, dass ich mich auf die richtige Stelle bewerbe.
Als Karriere-Interessent:in möchte ich dieselben Felder vorfinden wie auf karriere.solcom.de, damit ich keine erhöhte Hürde wahrnehme und meine Bewerbung schnell abschicken kann.
Als Karriere-Interessent:in möchte ich meinen Lebenslauf als PDF (oder Word) hochladen können, damit ich keine Datei umkonvertieren muss.
Als Karriere-Interessent:in möchte ich optional ein Anschreiben und weitere Anhänge mitschicken können, damit ich meine Bewerbung vollständig präsentieren kann.
Als Karriere-Interessent:in möchte ich die Datenschutzhinweise sichtbar verlinkt bekommen und meine Zustimmung explizit bestätigen, damit ich verstehe, was mit meinen Daten passiert.
Als Karriere-Interessent:in möchte ich nach Submit eine SOLCOM-Bestätigungsseite sehen, damit ich weiß, dass meine Bewerbung erfolgreich abgeschickt wurde.
Als Karriere-Interessent:in möchte ich kurz darauf eine Bestätigungsmail bekommen, damit ich den Prozess als abgeschlossen wahrnehme.
Als Karriere-Interessent:in möchte ich die Bewerbungsseite per Lesezeichen erreichen, mit Browser-Back zurück zur Stellenseite navigieren und den Link teilen können, damit der Bewerbungs-Flow wie eine normale Website funktioniert.

HR-Stakeholder:in

Als HR-Stakeholder:in möchte ich, dass jede über die SOLCOM-Karriereseite abgeschickte Bewerbung im Personio-Recruiting-Backend ankommt, damit ich Bewerbungen wie bisher in Personio bearbeiten kann.
Als HR-Stakeholder:in möchte ich die Bewerbungs-Files (CV, Anschreiben) als Attachments in Personio sehen, damit ich nicht in zwei Tools nach den Dokumenten suchen muss.
Als HR-Stakeholder:in möchte ich, dass das System bei Versand-Fehlern automatisch mehrere Wiederhol-Versuche macht, damit flüchtige Störungen sich selbst auflösen.
Als HR-Stakeholder:in möchte ich per Mail benachrichtigt werden, wenn eine Bewerbung trotz aller Wiederhol-Versuche nicht zugestellt werden konnte, damit ich manuell aktiv werden kann.
Als HR-Stakeholder:in möchte ich in einer eigenen Recovery-Oberfläche fehlgeschlagene Bewerbungen sehen, Files herunterladen, erneut versenden oder „manuell erledigt“ markieren können, damit ich keine Entwickler-Hilfe brauche.
Als HR-Stakeholder:in möchte ich, dass Bewerbungs-Daten und Files nur so lange in Drupal liegen wie nötig — nach erfolgreicher Personio-Ankunft sollen sie automatisch gelöscht werden, damit wir DSGVO-konform mit minimaler Datenhaltung arbeiten.
Als HR-Stakeholder:in möchte ich benachrichtigt werden, wenn eine Bewerbung länger als 24 h ohne Personio-Bestätigung bleibt, damit ich prüfen kann, ob Personio die Mail empfangen hat oder das Import-Mapping in Personio gebrochen ist.
Als HR-Stakeholder:in möchte ich die Recovery-Oberfläche über die HR-Rolle nutzen können, ohne dass mir Drupal-Admin-Vollzugriff gegeben werden muss, damit Berechtigungen sauber abgegrenzt bleiben.

Redakteur:in / PO

Als Redakteur:in möchte ich keinen Mehraufwand pro neuer Stelle haben — das Bewerbungsformular soll automatisch für jede neue Vacancy verfügbar sein, damit ich neue Stellen wie bisher anlegen kann.
Als PO möchte ich eine klare Tracking-URL pro Bewerbungsseite haben (/karriere/<slug>/bewerben), damit Analytics und Conversion-Tracking pro Stelle ausgewertet werden können.
Als PO möchte ich, dass die Bewerbungsseite in SOLCOM-Markenwelt erscheint (Lime-Akzent, Montserrat, ScalaSans, Sticky-Apply-Bar-Kontext), damit die Marken-Konsistenz über den gesamten Karriere-Funnel erhalten bleibt.
Als PO möchte ich, dass im Notfall (z. B. wenn der Personio-Inbox-Import auf SOLCOM-Seite strukturell scheitert) der Apply-CTA wieder auf die Personio-Hosted-Page redirecten kann, damit Bewerbungen weiter angenommen werden, während die Störung behoben wird.

Implementation Decisions

Module & deep-module-Extraktion

Custom-Drupal-Modul solcom_vacancy_application kapselt den gesamten Apply-Flow. Drei Deep Modules (kleines API-Surface, viel interne Logik, isoliert testbar) werden extrahiert, plus eine flache Service-Klasse und die Drupal-Plugin-/Controller-Schicht:

Schicht	Klasse	Verantwortlichkeit
Deep	`PersonioApiClient`	Personio-v2-API-Wrapper für Webhook-Subscription und Smoke-Test-Read-back. Token-Cache via Drupal-State, Retry-on-401 mit Re-Auth, JSON-Parse. Einziger Swap-Point für Future-Refactor zu Pfad A (Multiposting-Scope) — ein Method-Body wechselt, Pipeline bleibt.
Deep	`PersonioMailBuilder`	Erzeugt aus WebformSubmission-Entity + Files-Liste ein fertig komponiertes `Email`-Objekt mit strukturiertem Text-Body, Attachments und Subject mit Tracking-Hash. Tracking-Hash-Generierung ist private Methode mit deterministischer SHA-256-Ableitung aus Submission-UUID + Shared-Secret. Kein Drupal-Side-Effect.
Deep	`PersonioWebhookSignatureVerifier`	HMAC-basierte Signatur-Prüfung für eingehende Personio-Webhook-Requests. Input: Raw-Request-Body + Signatur-Header + Shared-Secret. Output: bool. Reine Funktion, keine I/O.
Shallow	`ApplicationLifecycleService`	Wrappt Submission-Storage-Operationen entlang der Lifecycle: Lookup via Tracking-Hash oder Email, ACK-Mark, PII+Files-Purge nach ACK. Wenig interne Logik, viel Drupal-API-Adapter.
Plugin	`PersonioQueueHandler`	Webform-Submit-Handler-Plugin. Speichert Files in `private://applications/<submission-uuid>/` und enqueued ein Queue-Item mit Submission-ID.
Plugin	`PersonioApplicationWorker`	Drupal-QueueWorker-Plugin. Lädt Submission, ruft `PersonioMailBuilder`, sendet via MailManager. Verwaltet Custom-Retry-Counter (5 Versuche, Backoff-Sequence) und triggert DLQ-Notification an HR.
Controller	`VacancyApplicationFormController`	Sub-Route `/karriere/<slug>/bewerben`. Lädt Vacancy-Node, rendert Stellenkontext-Header + Webform `vacancy_application` mit injizierten Hidden-Fields.
Controller	`PersonioWebhookController`	Endpoint `/personio/webhook/application-created`. Verifiziert Signatur via `PersonioWebhookSignatureVerifier`, ruft `ApplicationLifecycleService::ack`.
Controller	`DlqAdminController`	Admin-Route `/admin/karriere/dlq`. Listing failed Submissions + Files-Download + Re-Queue-Action + „Manuell erledigt“-Mark. Permission `manage karriere dlq`.
Drush	`solcom:personio:webhook-subscribe`	One-Time-Setup. `POST /v2/webhooks/subscriptions` über `PersonioApiClient`, persistiert Subscription-ID in Drupal-State.
Drush	`solcom:personio:smoke-test`	Production-Health-Check. Erzeugt markierte Test-Application gegen Dummy-Stelle 2635453, durchläuft Submit-Flow, verifiziert via Personio v2 Read-back.
Hook	`hook_cron`	ACK-Timeout-Cron: prüft Submissions im Status `sent_pending_ack` älter 24 h, schickt HR-Mail.

Webform-Topologie

Eine geteilte Webform-Entity vacancy_application. Vacancy-Kontext (Personio-Job-ID, Stellentitel, Vacancy-Node-ID) wird per hook_webform_submission_form_alter aus Route-Parametern als Hidden-Fields injiziert.
Skaliert ohne Mehraufwand pro neuer Personio-Stelle, Field-Schema bleibt Single-Source-of-Truth, Submissions zentral auswertbar.

Form-Placement & Routing

Eigene Drupal-Sub-Route /karriere/<slug>/bewerben, angelehnt an pathauto-Pattern /karriere/[node:title].
Apply-CTA auf Vacancy-Detail-Page (existierende sticky-apply-bar SDC) wechselt von externer field_apply_url auf interne Sub-Route. ADR-0014 (Vacancy-Canvas-Topologie) bleibt unverändert.
Bookmark- und Share-fähig, Browser-Back funktioniert, klare IA pro Stelle.

File-Upload-Profil

Max 3 Files (CV pflicht, Anschreiben optional, weitere Anhänge optional), max 10 MB pro File, Whitelist PDF/DOC/DOCX.
Files werden tempär in private://applications/<submission-uuid>/ abgelegt — Pipe-Through ist durch die Queue-Entscheidung explizit nicht möglich, weil der Worker zeitlich vom Submit entkoppelt ist.
Kein ClamAV-Layer in Drupal — Personio scannt eingehende Bewerbungen selbst.

DSGVO-Profil & Conditional-Retention

Minimal-Konform: Pflicht-Checkbox „Datenschutzhinweise gelesen“ mit Link auf /datenschutz. Wording und Layout 1:1 aus karriere.solcom.de-Referenz.
Rechtsgrundlage Art. 6 (1) (b) DSGVO „vorvertragliche Maßnahmen“, keine Einwilligungs-Pflicht für die Verarbeitung selbst. Hinweispflicht Art. 13 erfüllt.
Conditional-Retention: bei Personio-ACK → Drupal purgt Submission-PII-Felder + Files. Bei DLQ-Erschöpfung → Submission + Files bleiben persistent als HR-Recovery-Layer.
Auftragsverarbeitungs-Vertrag mit Personio ist Vorbedingung; Fakten-Check bei HR/Legal als Sub-Task.

Queue-Mechanismus & Retry-Strategie

Drupal Core Queue API plus Custom-Retry-Counter (max 5 Versuche, Backoff 1 min/5 min/15 min/1 h/6 h).
Zero Composer-Deps, deckt SOLCOM-Volumen (geschätzt < 50 Submits/Tag) locker ab. Bei späteren External-API-Queues kann auf advancedqueue migriert werden ohne Architektur-Bruch.
QueueWorker läuft via Cron (Default) und manuell via drush queue:run solcom_personio_application_queue für Smoke-Tests.

Personio-Mail-Format

Subject: Bewerbung: <Stellentitel> (Personio-Job-ID <id>) · <Bewerbername> · trace:<hash>
Body: strukturierter Key-Value-Text (z. B. Vorname: ... / Nachname: ... / Email: ... / Telefon: ... / Anschreiben (Text): ...).
Attachments: CV (Pflicht), Anschreiben (optional), weitere Anhänge (optional).
Tracking-Hash dient zur deterministischen Zuordnung Webhook-ACK ↔ Drupal-Submission unabhängig von Email-Match.

Webhook-Subscription & ACK-Handling

One-Time-Setup via drush solcom:personio:webhook-subscribe: POST /v2/webhooks/subscriptions über PersonioApiClient. Scope recruiting:write deckt Webhook-Konfiguration (spike-verifiziert).
Subscribed wird auf Event application.created mit Drupal-Receiver-URL /personio/webhook/application-created und Shared-Secret für Signatur-Verifikation.
Subscription-ID wird in state:solcom_personio.webhook_subscription_id persistiert.
Bei Webhook-Empfang: HMAC-Signatur via PersonioWebhookSignatureVerifier prüfen, Submission via Tracking-Hash oder Email matchen, Status auf acked setzen, Personio-Application-ID in Submission-Meta speichern, PII+Files purgen.

Credentials & Storage

Personio-API-Credentials (Client-ID + API-Key, papi-<REDACTED>-Format) liegen im Drupal-Key-Storage: key.key.solcom_personio_client_id und key.key.solcom_personio_api_key, Provider env.
Env-Vars PERSONIO_CLIENT_ID und PERSONIO_API_KEY in .ddev/config.local.yaml (lokal, gitignored) und Mittwald-Env (production) analog zum bestehenden Salesforce-Pattern.
Personio-Inbox-Adresse für Apply-Routing liegt config-overridable in settings.local.php, nicht in config/sync/ — vermeidet Leakage in den Git-Tree.
Webhook-Shared-Secret wird beim One-Time-Webhook-Subscribe von Personio generiert und im selben Key-Storage abgelegt: key.key.solcom_personio_webhook_secret.

Spam-Protection

Nur Webform-Honeypot + Time-Based-Heuristik (Submits unter 5 Sekunden werden silently rejected). Kein CAPTCHA initial.
Niedrigste User-Reibung, DSGVO-trivial. Refit auf Friendlycaptcha falls Spam-Volumen nach Launch steigt.

DLQ-Admin-UI

Custom Drupal-Admin-Route /admin/karriere/dlq.
Listing: pro failed Submission — Bewerber-Name, Stelle, Failure-Reason, Files-Download-Link, Action „Re-Queue“, Action „Manuell erledigt“.
Permission manage karriere dlq wird der HR-Rolle zugewiesen. Andere Rollen sehen die Route nicht (HTTP 403).

Testing Decisions

Test-Strategy ist Full-Suite — Deep-Module-Tests für interne Logik, Plugin-Tests für Worker- und Handler-Lifecycle, Functional-Tests für externe Boundaries, plus Drush-Smoke-Test als Production-Health-Check. Tests prüfen externes Verhalten, nicht Implementation-Details.

Modul	Test-Typ	Was getestet wird
`PersonioApiClient`	Kernel + Guzzle-Mock	Token-Cache-Verhalten, Retry-on-401 mit Re-Auth, JSON-Parse, Error-Mapping. Snapshot-Tests für Request-Payload-Shape (Webhook-Subscribe, Application-Read-back).
`PersonioMailBuilder`	Kernel + Snapshot	Email-Body-Snapshot pro Field-Profile (mit/ohne Anschreiben, mit/ohne weitere Anhänge), Subject-Format mit Tracking-Hash, Attachments-Liste. Hash-Generierung deterministisch mit Fixed-Seed.
`PersonioWebhookSignatureVerifier`	Unit	Valid + invalid + replayed Signaturen, Missing-Header, abgelaufener Timestamp. Drei-vier Assertions, schneller Lauf.
`PersonioApplicationWorker`	Kernel mit Mocks	Worker-Lifecycle: Item picken → MailBuilder rufen → MailManager.send rufen. Retry-Counter-Increment bei MailManager-Exception. DLQ-Notification nach 5 Versuchen.
`PersonioWebhookController`	Functional	End-to-End mit synthetisch-signiertem Webhook-Payload: HTTP-POST → Submission-Status `acked`, Files purged, Personio-App-ID in Submission-Meta. Plus Negative-Cases: invalid signature → HTTP 403, kein State-Change.
`DlqAdminController`	Functional	Admin-User mit Permission sieht Listing, Re-Queue-Action funktioniert (Item landet wieder in Queue), „Manuell erledigt“-Mark setzt Status. Ohne Permission HTTP 403.
`VacancyApplicationFormController`	Functional	Sub-Route rendert mit Hidden-Fields (Job-ID, Stellentitel, Vacancy-Node-ID). Submit erzeugt Submission + Queue-Item + Files in `private://`. Navigation auf Danke-Seite.
`solcom:personio:smoke-test`	Production-Health-Check	Drush-Command erzeugt markierte Test-Application gegen Dummy-Stelle 2635453, durchläuft Submit-Flow, verifiziert via Personio v2 Read-back. Eigener Test-Lauf außerhalb der CI-Suite. Cleanup-Option im Command oder manuell im Personio-Recruiting-Backend.

Prior Art

Kernel-Tests mit Guzzle-Mock: web/modules/custom/solcom_salesforce/tests/Kernel/SalesforceClientTest.php (existierendes Pattern für OAuth-Refresh + Token-Cache).
Functional Webhook-Test: web/modules/custom/solcom_personio/tests/Functional/XmlPullingTest.php (existierendes Pattern für externes-Trigger-Test).
Drush-Smoke-Test-Pattern: existierender solcom:salesforce:sync-Drush-Command (ohne Smoke-Variante — das ist Neuland für SOLCOM, lehnt sich aber an Personio-eigene Health-Check-Konventionen an).

Out of Scope

Pfad A (direkter HTTP-POST gegen Personio Recruiting API): ist Future-Refactor-Option. Aktivierung hängt am Outcome der parallelen, nicht-blockierenden Klärung mit Personio-Account-Manager (Multiposting-Partner-Scope). Falls aktiviert: 1-PR-Refactor des QueueWorker-Bodies in eigener Folge-Story, kein Architektur-Bruch.
Application-Updates über Drupal (PATCH-Pfad): kein Edit-Workflow für Bewerbungen auf Drupal-Seite. Bewerbungs-Änderungen passieren in Personio.
Multi-Step-Form-Wizard: die Form bleibt Single-Page (analog Personio-Referenz). Multi-Step ist künftige UX-Story, wenn Drop-Off-Analyse das nahelegt.
Talent-Pool-Opt-In als separate Einwilligung: nicht in Scope. Wenn Personio das benutzt, ist es Personio-Tenant-Setting, nicht Drupal-Form.
CAPTCHA-Layer: nicht Scope des MVP. Refit-Story, falls Spam-Volumen Honeypot/Time-based-Heuristik überfordert.
ClamAV-Virenscan in Drupal: nicht Scope — Personio scannt eingehende Bewerbungen selbst.
Multi-Tenant-Personio: nicht Scope. Genau ein Personio-Tenant (SOLCOM), eine Inbox-Adresse, eine Webhook-Subscription.
Bewerber:innen-DOI (Double-Opt-In): nicht erforderlich nach Art. 6 (1) (b) DSGVO, daher nicht in Scope.
Pfad B (Hosted-Page-Redirect): bleibt als Notfall-Fallback dokumentiert, aber nicht aktiv verfolgt. Nur falls Personio-Inbox-Konfiguration strukturell scheitert.

Further Notes

Spike-Evidence (17 Live-Probes, 2026-05-25)

Vor Architektur-Lock wurde der Personio-API-Surface systematisch geprobed. Zusammenfassung im Story-Hub-Abschnitt #spike-result in F-100. Kern: v2-Recruiting ist vollständig read-only (kein POST für Application-Create), POST /v1/recruiting/applications existiert (OPTIONS-Discovery bestätigt), ist aber für Standard-Recruiting-Credentials gated (HTTP 401 statt 404). Daraus: Pfad A scheidet für MVP aus, Pfad C+ (Email-Inbox-Import + Webhook-ACK) ist der einzige durchgängig erreichbare Mechanismus.

Credential-Hygiene

Während der Grilling-Session wurden Live-Personio-Credentials (Client-ID + API-Key im papi--Format) im Chat geteilt. Credential-Rotation ist Sub-Task (siehe P2503-90.7): vor Production-Deploy müssen die Credentials in Personio neu generiert und im Drupal-Key-Storage (Provider env) abgelegt werden. Die in der Grilling-Session offen liegenden Werte gelten als kompromittiert und dürfen nicht in Production verwendet werden.

Abhängigkeiten

SOLCOM-Personio-Admin konfiguriert die eingehende Personio-Inbox-Adresse, prüft das Mail-Parsing-Verhalten des SOLCOM-Tenants und stellt sicher, dass „Custom Apply URL“ pro Job auf das Drupal-Sub-Route-Pattern gesetzt werden kann.
Auftragsverarbeitungs-Vertrag mit Personio existiert und ist HR-/Legal-seitig dokumentiert (Faktenfrage, Vorbedingung der Implementation).
Mail-Server-Setup (Symfony Mailer) versendet zuverlässig an externe Mailadressen; SPF/DKIM/DMARC für die Absender-Domain sind konfiguriert, damit Personio die eingehenden Bewerbungs-Mails nicht in Spam filtert.
ADR-0014 (Vacancy-Canvas-Topologie) bleibt unverändert — Apply-CTA innerhalb existierender Section, Ziel-URL wechselt von external field_apply_url auf internal Sub-Route.
ADR-0035 (Personio-XML-Anonymous-Pulling) bleibt unverändert — Inbound-XML-Feed ist davon unabhängig.
ADR-0047 (geplant) verankert die Topology-Decision (C+ Email-Inbox + Webhook-ACK vs. A direkter API-POST vs. B Hosted-Page-Redirect). customer-lens-reviewer läuft als Decision-Gate vor ADR-Lock.
PRD 2026-05-02-personio-vacancy-integration-prd Out-of-Scope-Klausel „Bewerbungs-Formular auf Drupal“ wird im Rahmen der ADR formal aufgehoben.

Sub-Task-Drafts (User-Approval pro Ticket)

Geplante Decomposition in 10 Sub-Tasks. Jeder Sub-Task wird einzeln in Jira angelegt; das tatsächliche Posten ist Stakeholder-Aktion (User-Approval, kein autonomes Posten).

P2503-90.1 — Webform-Entity + Sub-Route + Vacancy-Kontext-Injection (UI-only, kein Submit)
P2503-90.2 — Submit-Handler + Queue + private://-Storage
P2503-90.3 — QueueWorker + PersonioMailBuilder + Personio-Inbox-Versand
P2503-90.4 — Webhook-Subscription + Webhook-Receiver + ACK-Handling + Conditional-Retention
P2503-90.5 — DLQ-Admin-UI
P2503-90.6 — solcom:personio:smoke-test Drush-Command + Kernel-Tests + Mock-Coverage
P2503-90.7 — Personio-API-Credentials rotieren und im Drupal-Key-Storage einpflegen (Sicherheits-Sub-Task)
P2503-90.8 — Auftragsverarbeitungs-Vertrag mit Personio prüfen (HR/Legal-Sub-Task)
P2503-90.9 — Personio-Inbox-Adresse + Custom-Apply-URL pro Job im SOLCOM-Tenant konfigurieren (Personio-Admin-Sub-Task)
P2503-90.10 — Personio-Account-Manager kontaktieren, Multiposting-Partner-Scope klären (parallel, Outcome bestimmt Future-Refactor-Option Pfad A)

Wiki-Promote (geplant)

Nach Implementation-Start wird docs/wiki/vacancy-personio-integration.html als aggregierter Anker promoted: Vacancy-Mirror (ADR-0035) + Apply-Flow (P2503-90) + IT-Landscape-Edge E15 + Spike-Result. Erfüllt das 3-Strand-Threshold-Kriterium der html-doc-authoring-Skill-Konvention.