Approval Assistant AI Agent approval hyperlinks not working in Microsoft Teams

[Patrick Tipps1]

Hi all,

I'm having an issue where the Approval Assistant AI Agent doesn't present clickable hyperlinks to route users to the portal. It's just giving the RITM numbers as plain text.

This issue is not happening within the virtual agent within ServiceNow, only in Microsoft Teams.

The customer I'm working for only has one Microsoft tenant and it's currently connected to prod so very little troubleshooting can be done. 

Does anyone know of any reason why hyperlinks would show up in one place and not the other?

This issue needs to be fixed asap so I could really use some help.

Thanks!

[Aravind2799]

Hi @Patrick Tipps1 ,

This is almost always a rendering difference between channels rather than a bug in the agent. The ServiceNow web client and Microsoft Teams don't interpret the same markup, so a link that renders correctly in one can show up as plain text in the other.

The most common causes:

1. Relative URLs. If the agent or its tool returns a link like /sp?id=ticket&table=sc_req_item&sys_id=..., the web client resolves it against the instance domain and it works. Teams has no base URL to resolve it against, so it's dropped or shown as text. Links sent to Teams need to be absolute, for example built with gs.getProperty('glide.servlet.uri').
2. HTML instead of Markdown. The web client renders HTML anchor tags. Teams messages support only a subset of Markdown and generally won't render raw <a href> tags. A Markdown link in the form [RITM0012345](https://instance.service-now.com/sp?id=...) is much more reliable across both channels.
3. The LLM's formatting. If the agent is left to decide how to present the record, it may not output a link at all, or may format it inconsistently. Add an explicit instruction to the agent, or better, have the tool return a ready-made absolute URL so the model only has to pass it through.

You can troubleshoot safely in prod without touching the Teams connection. Open the conversation records for an affected Teams session (the sys_cs_conversation / sys_cs_message tables) and compare the raw outbound message with the same interaction in the web client. That will show you directly whether the payload contains a relative URL, an HTML anchor, or no link at all.

For the fix, I'd update the tool or script that looks up the RITMs to return the full portal URL. Then update the agent's instructions to present each record as a Markdown link using that URL. You can validate the output in the web client in a sub-prod instance first. Once the payload contains an absolute Markdown link, it should render in Teams as well.

If you need to test against Teams before prod, consider a separate Microsoft 365 developer or sandbox tenant connected to a sub-prod instance. That way you're not dependent on the customer's single tenant.

---

I'd verify the exact table names for AI agent conversation logs on the customer's release before posting, since Now Assist AI agent execution may also be logged in its own tables. Pointing to the right one makes the safe-in-prod suggestion more useful.