Quick question about WEM agent login mismatch with BYOC trunk status

Quick question about why our workforce engagement manager (WEM) dashboard is showing agents as ‘available’ even when their assigned BYOC trunks are in a failed SIP registration state. we are running Genesys Cloud version 2023-04-W01 and using the native WEM integration for attendance tracking. the issue is specific to our Singapore region trunks (SG1-SG15).

normally, if a trunk drops, the outbound dialer handles it gracefully, but here the WEM agent state does not reflect the underlying connectivity issue. we have 15 BYOC trunks managed via IaC, and about 40% of them are currently flapping between 401 Unauthorized and 408 Request Timeout due to carrier-side credential resets. the agents logged into these trunks are still showing as ‘Ready’ in WEM, which messes up our shrinkage calculations.

i checked the analytics API endpoint /v2/analytics/wfm/summary and the agent_state field returns READY regardless of the trunk health. is there a specific dependency between WEM agent status and trunk registration that we are missing? or is this a known limitation where WEM only cares about softphone status, not the actual SIP trunk connectivity?

we tried adding a custom metric in Architect to force a state change if the trunk fails, but the metric definition seems to ignore the SIP registration status. the flow timeout mismatch we discussed earlier might be related, but this feels more like a data sync issue between the telephony layer and the WEM layer. any insights on how to decouple or correctly link these states? we need accurate attendance data for payroll, and currently, agents are being paid for time they are technically unable to handle calls due to trunk failures.

It depends, but generally… The WEM dashboard relies on presence state from the platform APIs, not directly on SIP trunk health. A trunk failure doesn’t automatically change an agent’s state unless the system detects a hard disconnect or failed registration attempt tied to that specific user’s line.

You likely need to verify if the agents are still registered via a different route or if the “Available” state is cached. Check the SIP logs for the specific agents in the SG region. Look for this pattern:

SIP_REG_FAIL: 408 Request Timeout; trunk_id=SG1-SG15; user_id=agent_123; status=REGISTRATION_LOST

If you see REGISTRATION_LOST, the presence service should update. If not, the issue might be in how the BYOC edge proxy handles the heartbeat. Ensure the presence attribute in the webhook payload sent to ServiceNow (if you are syncing states there) is explicitly mapped to offline when the trunk health check fails. Cross-reference the WFM integration docs for the latest presence sync intervals.