Onboarding Journeys That Start Too Early and Reach the Wrong People

Diagnosis. Day 1 activities are scheduled as offsets from the start date held on the HR profile at the moment the journey starts. If that field is blank, late-arriving, or overwritten by a default, the offsets resolve against the journey trigger date instead - which is why roughly one in five fires early, and why the failures are concentrated in records created close to the sync window.

Redesign principles

1. Gate the trigger on the start date being present and in the future. A journey that cannot compute its own schedule should not start.
2. Use wait-until conditions with absolute dates, not fixed "N days after trigger" offsets. The date is the fact; the offset is a derived convenience that breaks silently.
3. Re-evaluate on profile update so a changed start date moves pending activities. Right now the sixty changes last quarter propagated nowhere, which confirms the journey is a one-time snapshot.
4. Message in the employee's timezone and confirm the date in the first communication, so a residual off-by-a-few-days error is caught by the employee rather than discovered on Day 1.

Test with a start date next month, one later this week, one already past, and one with no start date at all.

Audience design. Put the exclusion in the journey's audience/HR criteria - worker type is employee - rather than in a conditional activity or a skip inside the flow. Excluding at the audience means the journey never starts and no partial artifact (case, welcome email, task backlog) is created for the wrong person. Retrofitting exclusions inside the activity chain leaves you cleaning up half-started journeys.

Use HR criteria on the HR profile field, mapped from the system of record, in preference to an AD group or department. Contractor populations are frequently inside the same directory group as employees, which is the likely root cause here.

Safe default when worker type is blank: fail closed - no onboarding rather than wrong onboarding. A missed onboarding is recoverable in a day; a contractor enrolled in benefits is a compliance and payroll correction. Mitigate the cost of failing closed by alerting on audience matches that drop unexpectedly and by running a weekly reconciliation of employees with blank worker type.

Verification. Use audience preview before publish against a contractor, a new hire, and a record with a blank worker type. Do not rely on the pilot group alone.

Sync failure detection. A job that succeeds is not evidence that data arrived. Monitor three things: the scheduled job/import result itself; a row-count delta against the expected headcount movement, alerting on both unusual spikes and zero-change runs; and a content check - active employees whose profile has not been touched in N days. Add a downstream check on journey starts, since a sync failure shows up there first as a quiet day. Route alerts to the integration owner, not to a shared queue nobody owns.

The 38% empty breakdown. Performance breakdowns read fields on the case record, not on the employee record. Department is copied onto the case at creation by the HR template; if the template does not set it, or the profile lacked department when the case was created, the case's department is blank and the breakdown reports empty - even though the employee record now looks fine. That also explains why the empties likely cluster in the same newly acquired populations with incomplete profiles.

Fix order: set the department default in the HR template so new cases stamp it, backfill existing cases from the HR profile, and confirm the snapshot job is running so history is retained. Reporting on the employee's current department as a substitute will make historical trends shift retroactively - state which definition you are using and keep it consistent.