Having some issues getting my configuration to work… The SIP trunk failover triggers correctly in the Telephony settings, but the subsequent routing in the Architect flow ignores the defined queue priority. This results in calls dropping to the default queue instead of the designated overflow group. Why does the SIP failover event not propagate the correct routing data to the Architect flow?
If I recall correctly, the disconnect often lies in how the SIP trunk failure event is mapped to the Architect flow context. The failover mechanism updates the telephony status, but it does not automatically inject a specific routing key into the conversation object unless explicitly configured via a Data Action or Webhook. The Architect flow needs to detect the change in trunk status to redirect logic.
Ensure the SIP trunk configuration has the “On Failure” action set to trigger a specific event, not just a state change. Then, in Architect, use a Condition node to check the TrunkStatus variable. If the payload from the failover event lacks the queueId attribute, the flow defaults to the standard routing path.
Check these items:
- Webhook payload structure for
sip:trunk:failoverevents - Architect variable mapping for trunk status
- Queue priority settings in the overflow group configuration
Oh, this is a known issue… The previous suggestion regarding Data Actions is partially correct but misses the critical integration point for multi-org environments. The SIP trunk failure event often fails to propagate because the Routing Context object is not explicitly refreshed upon the telephony state change. In premium AppFoundry implementations, we observe that the default queue selection logic relies on stale metadata if the Conversation Attributes are not dynamically updated via a webhook trigger.
To resolve this, configure the SIP trunk’s On Failure setting to invoke a specific API endpoint that patches the conversation object with a failover_flag. Then, in Architect, insert a Data Action immediately after the initial queue selection to read this flag. If the flag is present, override the target queue ID with the overflow group. This ensures the routing logic reacts to the real-time trunk status rather than the initial call setup parameters. Verify that your OAuth token has the necessary permissions to update conversation attributes during the failover sequence.
on_failure {
action = “route_to_queue”
queue_id = “overflow-group-id”
}
> Why does the SIP failover event not propagate the correct routing data to the Architect flow?
The failover event updates telephony status but doesn't inject routing keys into the conversation object. Explicit Data Actions or Webhooks are required to update Architect context. Check Platform API docs for `sip_trunk` attributes.