We recently rolled out the Genesys Cloud for Microsoft Teams direct routing integration. The voice routing works perfectly. However, our QM team is hitting a wall.
When they try to complete and save a ‘Quality Management Evaluation’ for a call that was answered by an agent using the MS Teams endpoint (instead of the standard GC WebRTC phone), the UI throws a red toast error: ‘User not found in WFM hierarchy’. The evaluation data is lost. The user absolutely exists in Genesys Cloud, they have the correct roles, and they are assigned to a Management Unit. Why does the QM module break specifically for interactions handled via the Teams integration?
I ran into this during our SSO rollout! The issue is how the MS Teams integration populates the userId in the conversation data.
When a call routes to Teams, it often uses a ‘SIP Tie’ to pass the call to the Microsoft tenant. The resulting interaction record in Genesys Cloud sometimes logs the endpoint as an ‘External Contact’ or a ‘System Endpoint’ rather than mapping it back to the authenticated Genesys Cloud userId. Since QM evaluations require a valid, internal userId to attach the score to the WFM hierarchy, the save action fails because it thinks the call was handled by an unknown external party.
We use this in APAC. The point above is correct about the SIP tie, but there is a fix.
You need to ensure that the Active Directory sync (or SCIM) between Azure AD and Genesys Cloud is perfectly populating the email and SIP address fields. The Genesys Cloud routing engine tries to reverse-lookup the MS Teams SIP URI (e.g., sip:[email protected]) to find the matching Genesys Cloud user. If that specific SIP address is not listed under the user’s ‘Contact Information’ in Genesys Admin, the mapping fails, and the interaction becomes ‘Orphaned’ for QM purposes.
As a director overseeing these ops, I strongly advise checking the ‘Teams Integration App’ settings in GC.
There is a specific toggle called ‘Sync User Presence and Attributes’. If this was unchecked during setup, the user mapping tables aren’t updated. Once you fix the SIP address mapping as As noted above, you will unfortunately not be able to evaluate the historical calls that already failed. The mapping has to exist at the moment the interaction is created. Test it with a new call after updating the user’s SIP properties!