Channel Orchestration
Part of Lifecycle operations and monitoring
Building an inventory of active customer journeys
Build and verify a register of active customer journeys, including entry rules, waiting messages, sending systems and owners.
Build an inventory of every sending path that can affect customers now. For each path, record who can enter, what may still send and who can investigate an exception. A list of journey names cannot answer those questions.
Find the active paths
Start with each messaging workspace's running automations. Add scheduled campaigns, sales sequences and service tools that may contact the same customers. Keep a quiet journey in the register until its state is explained: it may be correctly idle, missing a trigger or left running after its purpose changed.
Customer.io's automations page can be filtered by name, trigger and status. That helps find workflows in Customer.io; it does not reveal sends scheduled in another tool. Reconcile the combined list against recent sending records from each system.
Record what each path can do
Use one row per active sending path, with a stable ID and its configured state.
Field / Question it answers
- Purpose and customer task
- Why does the path exist?
- Entry source and counting unit
- Does it start from a person, account, order or task?
- Trigger and key filters
- What evidence admits someone?
- Channels and sending systems
- Where can a message be prepared or sent?
- Waiting steps and expiry
- Which messages can become stale?
- Exit and repeat-entry rules
- When does this instance end, and can another begin?
- Operational owner and escalation route
- Who can resolve an exception?
- Last verification and open concern
- How current is the record?
Keep references to the configured workflow and approved message versions in the organisation's internal register. The inventory locates active paths; detailed content mapping and formal change approval have their own records.
Verify each row
Compare the register with the live trigger, filters, delays, message settings and exit conditions. In Customer.io, a running automation may contain a message set to Queue Draft, which generates drafts without sending them automatically. Exit criteria are configurable and depend on the automation's trigger and settings. Record the actual behaviour rather than assuming the automation's status describes every message.
Inspect a recent history that entered and a source record that appears eligible but did not. Check the identity and time basis before deciding that entry was missed. Customer.io's profile activity looks back 30 days in its entrance troubleshooting view, so older cases may need another retained record.
Keep it current
Update the row when a path starts or stops, changes its entry or exit rule, adds a channel, or changes a data source. At each operating review, compare the register with platform lists and recent sends. Give any mismatch an owner and a date for resolution.
The inventory is useful when someone can locate affected customers and waiting sends without reconstructing the programme from memory.
