Intent is born where work is asked for. Upstream connectors put Triage’s diagnostic questions inside the tools requesters already live in (starting with Microsoft Teams) so the decision is made at the moment of need.
The default surface. Triage’s full diagnostic runs as a web application, with answer validation, conditional branching and guidance beside each question.
The web diagnostic is built to resist gaming: every answer is scored by algorithm, contradictory combinations are flagged as mismatches, and each flag is recorded for review.
Six scored questions, drawn from 29 question and answer types, with a channel recommendation at the end.
The Triage interface embeds into your intranet or internal portal pages via iframe or SSO redirect. In ServiceNow it runs as a Service Portal widget on Employee Center: see it below.
Whether the requester answers in the browser, Teams, Google Chat, or Slack, the scoring, the evidence trail and the Intent Record are identical.
The requester never leaves the conversation. Each question arrives as an Adaptive Card, Microsoft’s interactive message format.
The next question only arrives after the current one is answered - the fixed-order intake, preserved in chat.
Submitting replaces the card with a read-only copy of the answer.
Single sign-on through Entra ID, Microsoft’s identity service, confirms who is answering without a separate login.
The final card shows the recommended channel, the scores behind it and the Intent ID. When composerID confirms the publish, the card gains a link to the record it created. Teams developer notes →
The same questions and the same scoring, drawn with Block Kit, Slack’s native message-layout format. The Slack renderer already ships in the reference implementation; the transport is on the roadmap.
Questions render as message blocks with radio options and Slack’s green Submit; answering rewrites the message in place.
Slack does not hold the rules. The fixed question order, the locked answers and the discarding of abandoned diagnostics are all enforced by the gateway that scores the answers. Slack developer notes →
The same questions and the same scoring, drawn with Cards v2, Google Chat’s native card format. The Google Chat renderer already ships in the reference implementation; the transport is on the roadmap.
Questions render as cards with buttons; answering updates the message in place, so the interactive elements are simply gone once a choice is made.
Each surface obeys its own design system, and the differences show.
Google Chat does not hold the rules. Google Chat developer notes →
The only surface where the request starts and the decision returns in the same system.
The widget sits on a topic page next to the Service Catalog and Knowledge Base, where requests already start.
The requester is already signed in to ServiceNow, so the widget reads their identity from the existing session: no separate login, and that name is recorded in the Compliance File.
Watch the bar above the widget: when the decision lands, the Intent ID is written into the originating ticket’s correlation_id field and its state changes to Routed.
ServiceNow developer notes → · ServiceNow as a destination →
A generic embeddable chat component for conversational surfaces.
It embeds in messaging platforms, intranet portals, mobile apps and custom front-ends that support a chat widget.
Unlike the Teams, Google Chat and Slack connectors, which use each platform’s native card system, the Chat Interface uses a standard message-and-reply pattern. Questions arrive as bot messages with inline option buttons; the chosen answer appears as your reply and locks.
The Chat Interface connects to the same Intake Gateway as every other surface. The component only draws the conversation.
A single Intake Gateway sits between the chat surface and Triage. Nothing about the diagnostic moves into the chat platform - scoring, routing, anti-gaming and the Compliance File stay server-side, identical to the web intake.