iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An HR sync can mistake an existing employee for a leaver and create a second account when its matching key relies on raw name strings. In Sergey Shinder’s account, a vendor API migration changed how accented text was represented: the names still looked the same, but the integration no longer matched them. A single failed match triggered deactivation, and a later run created a duplicate. The underlying lesson is to identify people with a durable HR-system ID and put safeguards around destructive lifecycle actions.
What happened in the HR sync
Sergey Shinder describes an hourly integration that created, updated, or disabled directory accounts using HR data. After the HR vendor migrated its API platform, the new feed represented accented text differently from the previous feed. In José’s case, the two name forms appeared identical to users, but the integration compared the raw strings as part of a composite key.
The key used first name, last name, and date of birth—not a stable employee identifier. When the incoming record no longer matched José’s existing directory record, the sync treated that account as absent from HR and disabled it. On a later run, the HR record appeared to have no corresponding account, so the integration created a new one.
Recommended Free Tools
Shinder reports that 23 employees with accented characters in their names were affected. He says the team restored existing accounts from the directory recycle bin, manually merged duplicates, and completed recovery by eleven. This is the count and timeline in his incident account, not a general measure of how often HR syncs fail. Read Shinder’s incident account.
#1 Best Overall
Why the two name strings failed to match
Text can have different underlying representations while rendering alike. Shinder says the old and new API feeds used different Unicode representations for accented text. Because the integration compared raw name strings, the visually identical names did not compare equal in its composite key. As he put it: “Two strings that look the same are not a promise that they are the same.”
The names were not invalid, and the incident does not show that Unicode generally caused a system defect. It shows what happened when a particular integration treated mutable, human-readable attributes as identity and used an exact string comparison.
Rank #2
Two design choices turned a mismatch into a duplicate
A fragile identity key
Names can be represented differently, and other personal attributes can change. A key built from first name, last name, and date of birth can therefore fail to recognize the same person. The IT Canvass ServiceNow Workday integration guide advises choosing a stable matching key and warns that email may change. Its recommendation is to use a stable worker identifier when available: “Pick a matching key that does not change.” See the integration guide.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Deactivation after one mismatch
The integration also acted on a single failed match as if it proved that an employee had left. That made an inconsistent or changed feed consequential immediately. The two issues compounded: the unstable key caused a false mismatch, and the immediate disablement turned that mismatch into an offboarding event.
How to make an HR identity sync safer
Match on a durable worker identifier
Use the employee or worker ID supplied by the HR system as the cross-system identity key where one is available. Treat names, email addresses, and other changeable attributes as profile data, not as the sole proof that two records belong to different people. The integration guide describes an upsert keyed on employee_number; confirm which identifier is stable and consistently populated in your own HR source.
Normalize text at the integration boundary
Apply a consistent text-normalization policy to inbound values before comparing, storing, or logging them. Shinder says the team added normalization. The incident supports doing this consistently; it does not establish a particular Unicode normalization form as mandatory. Normalization is a useful defense for text comparisons, but it cannot make a mutable name-based identity key reliable on its own.
Rank #4
Test more than the displayed name
Contract tests should verify how the integration handles equivalent-looking text and varied character sets, rather than checking only what a name looks like on screen. Include:
- Composed and decomposed forms of accented names.
- Names containing apostrophes.
- Names containing non-Latin characters.
- Comparisons after the same person’s profile attributes change.
Require confirmation before disabling an account
Do not treat one missing match as sufficient proof of termination when source data may be incomplete or inconsistent. Shinder says the team added a second agreeing run before disabling an account. Depending on the integration, a confirmation run or human review can help distinguish a genuine departure from a transient mismatch; define the behavior explicitly for your system.
Best Value
Exercise termination and rehire end to end
A successful hire and profile-update test does not establish that the lifecycle works correctly. Test a sequence that changes an employee attribute, terminates the worker, and then rehirs the same worker. Confirm that the original directory record is restored or reused, rather than leaving a duplicate. The Workday integration guide explicitly recommends termination-and-rehire checks as part of integration validation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Implementation choices to review
| Decision | Riskier approach | Safer control |
|---|---|---|
| Identity key | Match on mutable names, email, or a composite of personal attributes. | Use a stable employee or worker ID where the HR system provides one. |
| Offboarding | Deactivate immediately after one missing match. | Require a confirming run or review before deactivation. |
| Validation | Test only hires and ordinary profile updates. | Test termination followed by rehire and check for reuse of the original record. |
| Text handling | Assume visually identical names always compare equally. | Normalize consistently and test multiple representations and character sets. |
These safeguards address different failure modes: stable IDs reduce false identity mismatches, consistent text handling improves comparisons, lifecycle tests reveal duplicate-account behavior, and confirmation controls limit the impact of a bad or incomplete feed. HR platforms and directories differ, so verify available identifiers and recovery behavior in the systems you use.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
