Event Overview

Published by notify_eventbridge_of_manager_changes() in main.py, and only while processing the crm_systemuser_history table. During that table’s run the pipeline pre-scans extracted rows and compares each user’s manager_source_id against the current RDS state; any user whose manager changed (excluding protected users) is collected. The changes are sorted top-down by hierarchy depth and published in batches of 1,000 per put_events call.

This is a business/integration event, distinct from the audit-event envelope used by the other events on this service. It uses a different EventBridge envelope:

• DetailType: Hierarchy Updated
• Event name (in payload): rio.user.hierarchy.updated
• Source: rio.glue.crm_sync (note: different from the rio.platform audit source)
• Bus: EVENT_BUS_NAME ({env}-rio-events), falling back to default
• Batch size: 1,000 updates per event (EB_BATCH_SIZE)

Downstream

The event is consumed by the Identity & Hierarchy Service, whose ${DeployPrefix}-hierarchy-updates rule (rio-identity-service/infrastructure/lambda/template.yaml:168-179) matches:

source:              [rio.glue.crm_sync, rio.api.hierarchy_change]
detail-type:         [Hierarchy Updated]
detail.event_name:   [rio.user.hierarchy.updated]

The target Lambda recomputes each affected user’s hierarchy_path and level_1_id … level_10_id.

Because that rule also matches rio.api.hierarchy_change, the identity service’s own Hierarchy Updated (Variant B) lands in the same Lambda. A hierarchy change made through the API and one detected by this CRM sync are handled by identical code — which is why this event deliberately copies that payload shape rather than using this service’s usual audit envelope.

Payload Schema