Identifiers and Reference Data

Every integration in this category is a join between systems, and the join fails on whatever identifier someone chose casually.

Keying on people

Not the name. Names change, transliterate differently between systems, and repeat.

Not the email address. It changes on a name change or a domain migration.

A stable internal identifier, issued by whichever system is authoritative for people — usually the HR system or payroll.

A rehired person is the hard case. Same person, new employment record. Whether they get the same identifier determines whether their old timesheets are theirs, and both answers have consequences: reuse breaks the separation between employment periods; a new one breaks continuity of the individual's record and their access to it.

Decide it explicitly and write it down, because the default is whatever the first integration happened to do.

Keying on projects and cost centres

Codes get reused. A retired project code reassigned to something else silently corrupts every historical report.

Codes get renumbered in a reorganisation, and the mapping is usually in someone's spreadsheet.

Require: never reuse a retired code. It is free to obey and expensive to discover you did not.

Require: archive rather than delete, so historical entries remain interpretable.

Ask whether the product supports an effective-dated hierarchy — a cost centre that moved in the middle of a year. Most do not, and the workaround is a parallel set of codes.

The authoritative source

One system owns each kind of reference data, and the others read it.

People: HR or payroll.

Projects: the project or finance system.

Cost centres: finance.

The timesheet system owns time entries and nothing else.

Where it also maintains its own project list, the two will diverge, and reconciling them becomes a recurring job nobody assigned.

Synchronisation

One direction, from the owner to the timesheet system.

On a schedule and on demand, since a new starter cannot wait for tonight's run.

With deletions handled as deactivation, never as removal, or historical entries lose their referent.

With a report of what changed, because silent synchronisation failures are the kind that surface at period end.

Testing it

Rename a person in the HR system. Does their history follow?

Deactivate a project. Do existing entries survive, and is the code blocked for new entries?

Move a cost centre in the hierarchy. Do old reports still reproduce their original figures?

Break the connection for a day, deliberately, and see what the timesheet system does. Silent failure here is the defect worth finding before go-live.

The rehire decision

The case that has no obviously right answer and must be decided rather than defaulted.

Same person, new employment record.

Reuse the identifier: continuity of the individual's record and their access to it, and the separation between employment periods is lost.

Issue a new one: clean separation, and their old timesheets are no longer reachable by them.

Both have consequences. Decide with HR and payroll, write it down, and make the integration follow it — or the first integration to encounter a rehire decides for you.

Testing the reference data flow

Four actions that find what breaks before it breaks in production.

Rename a person in the source system. Does their history follow?

Deactivate a project. Do existing entries survive, and is the code blocked for new ones?

Move a cost centre in the hierarchy. Do old reports still reproduce their original figures?

Break the connection for a day, deliberately. Silent failure here is the defect worth finding before go-live rather than at period close.

Map identifiers before synchronising

CRM records demonstrate how names can look equal while IDs differ. Use this reference case to test creation, updates and duplicate handling.