The HRIS-to-Performance-Tool Sync Pattern That Stopped Our Review Cycle From Firing Against Stale Org Charts

The HRIS-to-Performance-Tool Sync Pattern That Stopped Our Review Cycle From Firing Against Stale Org Charts

Authored by: Kartik Chugh

The bug was not in any individual tool. The bug was in the integration layer between two tools that both believed they were the source of truth.

Two systems, both certain

We used BambooHR as our HRIS for org-chart, department, and active-status. We used Lattice as our performance and review tool. Both have an API. Both let you import an org structure. Both expose a manager-of-record field. So far, so normal.

What we did not understand at rollout was that Lattice keeps its own internal cache of manager-of-record, derived from the most recent import or sync. When an employee transferred in BambooHR, the transfer landed in BambooHR on the right date, but Lattice’s cache held the prior manager-of-record for a 7-day stale window we had not documented anywhere in our runbooks. During that 7-day window, every Lattice-triggered Slack reminder, every assignable review task, every analytics chart that referenced manager-of-record was pointing at the wrong person.

Multiply that 7-day stale window by the rate of internal transfers in a small fast-growing team. Multiply by the number of automated touchpoints (Slack DMs, calendar holds, review-cycle reminders). The 22 percent error rate stops being surprising. It stops being a bug too. It becomes the predictable output of a dual-source-of-truth system that no one explicitly arbitrated.

The trigger

The fix did not come from a vendor support ticket. It came from a Slack DM. One of our senior operators sent a single sentence in our internal HR channel: “I keep getting weekly check-in reminders that say my manager is Alex. Alex has not been my manager for three weeks. I think the reminder is wrong but I do not want to ignore it.”

That one sentence forced the question every HR ops team should ask before any tool integration: which system is the canonical source of truth for which attribute, and what is the freshness contract on every other system that consumes that attribute?

We had never written that down. So we wrote it down.

The canonical source-of-truth diagram

On a single page, we listed every employee attribute that any internal system needs: department, manager-of-record, active status, full-time/contractor flag, location, payroll-eligible date. Next to each attribute, we wrote the canonical system. For us:

  • Department: BambooHR
  • Manager-of-record: BambooHR
  • Active status: BambooHR
  • Full-time/contractor: BambooHR
  • Location: BambooHR
  • Payroll-eligible date: BambooHR
  • Performance rating: Lattice
  • Review cycle status: Lattice
  • 1:1 cadence: Lattice
  • Slack channel membership: derived from BambooHR department

Everything that touched org structure had to pull from BambooHR, not from Lattice’s cached copy. Lattice was allowed to cache for performance reasons, but the cache had to be invalidated within 24 hours of any BambooHR change, not 7 days.

The nightly sync script

We wrote a small script (about 80 lines of Python) that runs every night at midnight UTC. The script:

  1. Fetches the current org chart from BambooHR via API
  2. Fetches the current manager-of-record cache from Lattice via API
  3. Computes the diff
  4. Pushes the diff into Lattice via Lattice’s manager-of-record write endpoint
  5. Posts a summary of the diff to a private Slack channel called #ops-hr-sync

The reason for the Slack post is not the diff itself. It is the daily ritual. Anyone on the ops team who notices a row in #ops-hr-sync that looks wrong has 24 hours to flag it before the next sync overwrites it. Over the first month, we caught two manual entry errors in BambooHR (someone had typed the wrong department code) that would otherwise have propagated silently to Lattice.

The numbers since

Six weeks after the canonical-source diagram and the nightly sync went live:

  • Org-chart drift between the two systems fell from 22 percent to under 1 percent
  • Time from an internal transfer event to the correct manager-of-record showing in Slack reminders fell from up to 7 days to under 24 hours
  • The number of “is this notification wrong?” Slack DMs dropped to zero across the 6-week window
  • Our second HR tech rollout (an offboarding tool, this March) took 11 days from contract signature to first live use, compared to 38 days for the Lattice rollout. The difference was that we had the canonical-source-of-truth diagram already; we knew exactly which attributes the new tool was allowed to cache and which it had to pull live

What this generalizes to

The integration pattern that broke for us was not unique to BambooHR or Lattice. The same pattern fires every time you adopt a new HR tool: ATS, performance, learning, equity, comp planning, offboarding. Each new tool typically arrives with its own internal model of the employee record and its own caching behavior on attributes you have decided live elsewhere.

Before signing the contract on any new HR tech vendor, two things make the rollout faster:

First, ask the vendor for their org-chart sync SLA in writing. Not in support docs. In the contract or in a written addendum from a named vendor engineer. The support-docs version frequently lags the actual product behavior by months. We learned this the second time we had to confirm a sync window, when the support article said “near-real-time” and the actual sync was 7 days.

Second, before mapping the integration, build the canonical-source-of-truth diagram. Not after. Not during onboarding. Before. The diagram is the contract you are about to ask the new vendor to honor. Doing it after rollout means doing it under pressure, after you have already discovered drift in production.

What I would not do again

I would not assume that two HR tools with overlapping data models can be left to “figure out” sync. They cannot. One of them has to be canonical. The other has to be a subscriber with a written freshness SLA. If neither is canonical, drift is the default outcome and the data quality of every downstream signal (reminders, analytics, review fairness, audit defensibility) silently degrades.

I would also not skip the Slack visibility channel. The diff posted into #ops-hr-sync every morning is not technical instrumentation. It is a behavior change tool. The daily visibility makes anyone who breaks the sync own the fix, and it makes ops drift impossible to ignore for more than 24 hours.

The summary version, for a busy reader

Every HR tech rollout looks like a vendor integration. It is actually a data-source-of-truth integration. The vendor side is the easy half. The hard half is naming which system owns each attribute, writing that down in one diagram, and refusing to ship the integration until that diagram exists. Once you have it, the integration takes a day. Without it, the integration takes a month and quietly corrupts your data for six weeks before you notice.

Author Bio: Kartik Chugh, Cofounder, FORKOFF

Share:

Leave a Reply

Your email address will not be published. Required fields are marked *