Approval Assistant AI Agent approval hyperlinks not working in Microsoft Teams

Patrick Tipps1
Tera Contributor

‎10-01-2026 12:37 PM - edited ‎10-01-2026 12:37 PM

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!

0 Helpfuls
  • 622 Views
2 REPLIES 2

Aravind2799
Tera Expert

‎10-01-2026 12:42 PM

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.

0 Helpfuls

sanjaygupta
Tera Guru

Friday

This is usually a difference in how the two channels display the response, not a fault in the Approval Assistant. The ServiceNow web client and Microsoft Teams do not interpret the same formatting. The documentation says that in Teams, only the HTML tags Teams supports are rendered as normal tags, and links to ServiceNow records open in the base system portals unless you configure URL navigation. Community experts add that a relative link such as /sp?id=... works in the web client, which resolves it against the instance domain. Teams has no base URL for it, so it shows plain text.

You can check this without touching the production Teams connection:

  • Open the agent’s execution logs or the conversation record for the failing prompt, and read the actual response payload. It will show whether the RITM appears as a relative URL, an HTML anchor or no link at all. Confirm the exact log table for your release, since Now Assist agent runs may use their own tables.
  • If the payload has a relative or HTML link, change the tool or script that looks up the RITMs so it returns a full absolute portal URL. A Community answer suggests building it from the instance base URL, such as glide.servlet.uri.
  • Update the agent’s instructions so each record is shown as a Markdown link, for example [RITM0012345](https://yourinstance.service-now.com/...). Community members report Markdown links are more reliable than HTML across both channels.
  • Check the portal your links should open in, using Configure URL navigation for chat links in Conversational Interfaces settings, so the link goes to your portal rather than the default.
  • Validate the change in a sub-production instance first. If the link appears correctly in the web client, repeat it in production in a quiet window.

Separately, a Community reply says Virtual Agent table responses in Teams may not show record links the same way even when the table link settings are on, and suggests adaptive cards with buttons if they are enabled. If Markdown links still show as plain text after the checks above, an adaptive card is the next option to consider.

Sources:

0 Helpfuls