Integration  ·  People operations

How to build an org hierarchy sync

Somebody changes manager and their expense claims still route to the person who left in March. Here is the model behind a hierarchy that propagates, the prompts that build it, and what it takes to run in production.

Built with Tray Headless

  1. System Workday
  2. Step Detect change
  3. Step Resolve consumers
  4. Step Propagate dated
  5. System Okta
Also Salesforce

One source owns the hierarchy and every consumer reads it, with a reorganisation applied as a dated batch, not a stream of individual moves.

The short answer

What is an org hierarchy sync?

Four things make up an org hierarchy sync: one authoritative source with every consumer reading from it, changes propagated with their effective date rather than immediately, reorganisations handled as a dated batch instead of hundreds of individual moves, and a check that nothing is left routed to somebody who has gone. The part teams get wrong is treating a reorganisation as many small changes. Applying two hundred manager moves one at a time produces hours where approvals route to people who no longer manage anybody.

What matters here

  • The hierarchy decides approvals, routing and access. It is not reference data, it is a control.
  • Propagate with the effective date. A promotion effective next month should not reroute approvals today.
  • Apply a reorganisation as one dated batch. Two hundred sequential moves creates hours of inconsistent routing.
  • Check for orphans continuously: anybody reporting to a leaver, or to nobody at all.
  • Keep the history. Who approved what is a question about the hierarchy as it was, not as it is.

Who this is for

You run people operations or IT. The HRIS knows the org chart, and six other systems have their own stale copy of it.

How it works in practice

The path from a reporting line changing to every system honouring it.

  1. 1

    The HRIS is the single source

    Every other system reads. None of them write, and none of them keep a local override.

  2. 2

    Changes carry their effective date

    A promotion dated next month propagates next month, not the day it was entered.

  3. 3

    Consumers are resolved from a register

    Which systems use the hierarchy for what, so nobody has to remember the list.

  4. 4

    A reorganisation is applied as one dated batch

    Not as hundreds of individual moves, which leaves the estate inconsistent while it runs.

  5. 5

    Orphans are detected continuously

    Anybody reporting to a leaver, to nobody, or into a cycle.

  6. 6

    History is retained

    Because who could approve what last March is a question about the hierarchy then.

What the sync is made of

Four, and the third is what stops a reorganisation breaking a week of approvals.

One authoritative source

The HRIS. Every consumer reads and none write, because a local override is how two systems start disagreeing about who approves.

Effective-dated propagation

Changes applied on their date instead of on entry, so a future promotion does not reroute anything today.

Batched reorganisations

A restructure applied as one atomic dated change. Sequential moves leave approvals routing to nobody for hours.

Orphan detection

Anybody reporting to a leaver, to nobody, or into a loop. Each of those silently breaks an approval path.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    Set up, then list who actually consumes the hierarchy

    It decides more things than anybody expects.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are Workday and Okta, or
whatever we run in those seats.

I need the worker record with manager, department, cost centre, location
and effective dates, and from Okta how group membership and manager
attributes work.

Then build a consumer register: every system that uses the hierarchy, and
for what. Expense approval, purchase approval, access requests, ticket
escalation, CRM territories, performance review routing, payroll cost
centres.

That list is longer than people expect, and everything on it breaks
quietly when the hierarchy is stale. This is not reference data, it is a
control.
  2. 2

    Propagate with the effective date

    A future promotion should not reroute approvals today.

    Headless skills build-workflow tray-patterns 

    Use build-workflow. Read changes with their effective dates and schedule
propagation for that date instead of applying on entry.

A promotion entered in March effective from April changes approval
routing in April. Applying it in March means an expense approved by
somebody who is not yet their manager, which fails an audit even though
everybody behaved reasonably.

Handle a backdated change explicitly: apply it now, and report anything
that was routed under the old hierarchy in the intervening period so
somebody can decide whether it needs revisiting.

Write to every consumer on the register. Never let a system keep its own
override, because that is how two systems start disagreeing about who
approves what.
  3. 3

    Apply a reorganisation as one dated batch

    Sequential moves leave the estate inconsistent while they run.

    Detect a reorganisation rather than treating it as many individual
changes: several manager changes with the same effective date, or a
change affecting more than a threshold of people.

Apply it atomically, on the date, as one batch. Two hundred sequential
manager moves produces hours where some approvals route to the old
manager, some to the new one, and some to nobody.

Before applying, produce a preview: who moves, which approval paths
change, and anything that would become orphaned. Have somebody in people
operations read it.

After applying, verify every consumer reflects the new structure rather
than assuming the writes succeeded.

    The preview is the part worth insisting on. A reorganisation is the one change where an error affects hundreds of people simultaneously.

  4. 4

    Detect orphans continuously

    Each one silently breaks an approval path.

    Headless skills tray-gotchas 

    Use tray-gotchas, then check continuously for:

  Anybody whose manager is a leaver
  Anybody with no manager who is not the chief executive
  A reporting cycle, where two people manage each other, which happens
  more often than it should and breaks any recursive lookup
  A manager with no direct reports still receiving approvals
  A cost centre with no owner
  Anybody managed by somebody in a different legal entity, where that
  matters for approval authority

Alert on each rather than reporting them monthly. An approval routed to
a leaver does not fail loudly; it sits in a queue nobody watches until
somebody chases it.
  5. 5

    Keep the history

    Who could approve what last March is a question about the hierarchy then.

    Store the hierarchy as history rather than current state: each reporting
relationship with a valid-from and valid-to.

An audit asking whether a purchase was approved by the right person in
March is a question about March, and a current org chart cannot answer
it. Reconstructing from a stale export is guesswork.

Then report: changes propagated per period, propagation failures per
consumer, orphans by type, and consumers whose hierarchy differs from the
source, which should always be zero.

That last one is the health check. Any consumer drifting from the source
has a local override somebody added, and it will keep drifting.
  6. 6

    Check it end to end, then hand the consumer register over

    Because new systems adopt the hierarchy without telling anybody.

    Run the per-step schema checks and the whole-workflow audit before this
touches production. Test with a simulated reorganisation and confirm the
preview matches what actually happens.

Then open the same workflow in Tray Build so people operations and IT can
maintain the consumer register in the visual canvas. A new system that
uses the hierarchy and is not on the register is one that silently goes
stale.

What it connects to

One source and a longer list of consumers than anybody expects.

Workday

Read workers, managers, departments, cost centres and effective dates. The single source for all of it.

Reads

Okta

Write manager attributes and group membership, which most other systems then read from.

Reads and writes

Salesforce

Update role hierarchy and territory ownership, so forecast roll-ups follow the real org.

Writes

NetSuite

Update cost centre ownership and approval limits, which is where a stale hierarchy costs money.

Writes

Jira

Update approval and escalation paths so a ticket never escalates to somebody who left.

Writes

Slack

Alert on orphans and propagation failures, and send the reorganisation preview for review.

Writes

Snowflake

Hold the hierarchy as history, so who approved what in March is answerable.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Microsoft Dynamics 365, SAP S/4HANA, Google BigQuery, Microsoft Teams, Azure Active Directory or SAP SuccessFactors.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

The hierarchy decides who can approve and who can see. Stale is a control failure.

It lives on the platform, not in a terminal window

Scheduled effective-dated changes and continuous orphan checks run on the same engine, including the reorganisation that lands at midnight.

History is retained, not just current state

Every reporting relationship with its valid dates. An audit question about March cannot be answered by a current org chart.

No credential ever lands in the workflow itself

Writing manager attributes changes who can approve spend across the company. Scoped, held in your workspace and separately rotatable.

People operations own the consumer register

Which systems consume the hierarchy opens in Tray Build. A system missing from that list is one that silently goes stale.

Reorganisations preview before they apply

One change affecting hundreds of people at once is the case where an error is least recoverable and most visible.

Questions people ask

Why is the hierarchy a control rather than reference data?

Because it decides who can approve spend, who sees what, where tickets escalate and how forecasts roll up. A stale hierarchy means approvals routing to people who no longer hold the authority.

Why propagate on the effective date?

Because a promotion entered in March effective from April should not change approval routing in March. An expense approved by somebody who was not yet their manager fails an audit even though everybody acted reasonably.

Why batch a reorganisation?

Because applying two hundred manager moves sequentially leaves hours where some approvals route to the old manager, some to the new, and some to nobody at all.

What counts as an orphan?

Anybody reporting to a leaver, to nobody, or into a cycle where two people manage each other. Each silently breaks an approval path, and none of them fail loudly.

Why keep hierarchy history?

Because an audit asking whether something was approved by the right person last March is a question about the hierarchy as it was then, and a current org chart cannot answer it.

Vibe-coding app guides

Vibe-code an entire app with Helix

This moves the data between systems. It does not give anybody a screen to work in. Build that app in Claude Code, Codex or Cursor, then deploy and run it governed on Tray Helix. Same kind of guide, same kind of prompts.

How to build a headcount request tracker (opens helix.tray.ai in a new tab)

Related guides

People operations

How to build an HRIS to payroll sync

Sync effective-dated changes, respect the payroll cutoff, hold anything ambiguous instead of guessing, and reconcile every cycle. The prompts that build it.

IT and security

How to build access request and approval

Route to the system owner, grant with an expiry by default, provision automatically, and produce the access review as a by-product. The prompts that build it.

Last reviewed September 2026.