integration with Servicenow and teams issue

[dharmarajb1]

Hi all. I have integrated the teams with Servicenow and whenever I'm getting the approval for change request , I can get the pop up from the teams ui page. we can approve the request from here itself. the issue is like now , we can't get the approval was not hitting the Servicenow tool, the teams pop showing like approved but in the tool not reflected. could you please help on this issue and also we don't have the inbetween records of both tool and teams. what was the cause and how to troubleshoot this issue? some users only facing this issue.

[Vikram Reddy]

Hey @dharmarajb1,

This almost never turns out to be a bug in the Teams channel itself, it is an identity resolution problem on the ServiceNow side, and it is worth ruling that out before you chase anything else.

Here is the part that trips people up: when someone taps Approve on the adaptive card, Teams is not writing to sysapproval_approver directly. The click fires the Approve Sysapproval Approver Virtual Agent topic (shipped with the ITSM Virtual Agent Conversations plugin), and that topic runs in the context of whatever sys_user record the Teams identity resolves to. The card in Teams flips to "approved" as soon as the bot sends any response back, and that is just a client-side render of the Action.Submit reply, not proof the underlying script actually committed the change. So you can absolutely end up with a card that says approved while the topic errored out quietly on the ServiceNow side and never touched the record.

Since it is only hitting some users, my first suspect is the sys_user match. Email is not a unique field on sys_user, so if any of the affected users have a duplicate sys_user record, or their Azure AD UPN does not cleanly match the email on their primary record, the topic can resolve to the wrong user, or nobody, and fail silently. Pull those specific users' sys_user records and check for duplicates on email before anything else.

After that, go look at the Virtual Agent conversation history (the Conversation History module, or sys_va_conversation and sys_va_message if you are querying directly) for those users, filtered to the Microsoft Teams channel, around the timestamps they say they approved. That will tell you whether the topic even fired and whether it threw an error, which is far more useful than trying to reconstruct anything from the Teams side since Teams does not keep anything you can correlate back to ServiceNow. It is also worth opening the Approve Sysapproval Approver topic in VA Designer and stepping through it in test mode while impersonating one of the affected users, and checking whether an ACL or business rule on sysapproval_approver is scoped by role or group in a way that quietly excludes them.

I would bet on identity or ACL scope before I would bet on the channel itself being broken. If you can pull one of those conversation log entries and share what the topic actually did, happy to help narrow it down further.

Thank you,
Vikram Karety
Octigo Solutions INC

[Tanushree Maiti]

Hi @dharmarajb1 

• Ask the affected users sign out of their Microsoft Teams desktop app and sign back in.

• Ensure they are using the latest version of the Microsoft Teams client and that the ServiceNow Virtual Agent bot is not blocked by your Teams tenant administrator
• Check the Flow Designer execution logs if your integration uses the Microsoft Teams Spoke. Look for errored executions tied to the affected users
• Review your instance System Logs  for any REST API or Script Include errors originating around the time the approval was clicked in Teams.
• Check the Flow Designer execution logs if your integration uses the Microsoft Teams Spoke. Look for errored executions tied to the affected users
• Verify that the affected user (or the integration service account processing the API) has the necessary roles to update the Approver table.
• Ensure they are not being evaluated strictly as guest/unauthenticated users due to impersonation policies or missing Azure permissions
• Navigate to the sys_user table in ServiceNow and locate one of the affected users.
• Check their primary email field. Ensure this perfectly matches the email they use to log into Microsoft Teams and their Azure AD profile.   Check if their user account is active.