Event Overview

The org hierarchy is the manager chain, flattened onto every person as level_1_id … level_10_id plus a hierarchy_path. When that chain changes, everything downstream that answers “who reports to this manager” has to be recalculated. This event is the trigger for that work.

Read this carefully: Hierarchy Updated is emitted twice, on two different sources, with two different payload shapes. They are not interchangeable.

Variant A — the audit record

Variant B — the recalculation trigger

Variant B’s data block carries hierarchy_revision_id, a list of updates, and provisioning_source: "MANUAL". Entries are batched under a 240 KB ceiling (EVENTBRIDGE_ENTRY_SIZE_LIMIT, api/core/constants.py:121), because EventBridge caps entry size.

All three of source, detail-type and detail.event_name are configurable through settings; the values above are the fallbacks used when nothing is overridden.

Why there are two variants

Variant B is shaped to match the event that rio-ingestion-service publishes when the CRM sync detects a manager change — see HierarchyUpdatedByIngestion. Because both use detail-type Hierarchy Updated and detail.event_name rio.user.hierarchy.updated, a single rule catches hierarchy changes from either origin:

${DeployPrefix}-hierarchy-updates   (infrastructure/lambda/template.yaml:168-179)
  source:              [rio.glue.crm_sync, rio.api.hierarchy_change]
  detail-type:         [Hierarchy Updated]
  detail.event_name:   [rio.user.hierarchy.updated]

So a hierarchy change made through the API and one detected by the scheduled CRM sync both land in the same recalculation Lambda.

Who consumes it

• Variant B → this service’s own hierarchy recalculation Lambda, via the rule above.
• Variant A → the Audit Service, via its catch-all rule matching any source that begins with rio.

Payload Schema

The schema below documents Variant A, the audit envelope. Variant B’s shape is described in the table above and is structurally identical to HierarchyUpdatedByIngestion.