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. composerID then carries that decision downstream into the systems of record.
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. No separate app to find or remember.
Whether the requester answers in the browser, Teams, or Slack, the scoring, the evidence trail and the Intent Record are identical. Only the surface changes.
The requester never leaves the conversation. Each question arrives as an Adaptive Card, Microsoft’s interactive message format. Answering replaces the card with a read-only copy, and the decision and its Intent ID return to the same thread.
The next question only arrives after the current one is answered - the fixed-order intake, preserved in chat. Guidance is embedded in the card, exactly as on the web intake.
Submitting replaces the card with a read-only copy of the answer. Earlier cards stay in the thread as plain text, with nothing left to change.
Single sign-on through Entra ID, Microsoft’s identity service, confirms who is answering without a separate login. The requester is whoever is signed in to Teams, and that name is recorded in the Compliance File.
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 buttons; answering rewrites the message in place. Only the way the question is drawn differs from Teams.
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 only surface where the request starts and the decision returns in the same system. The diagnostic runs as a Service Portal widget on an Employee Center page, in the requester’s existing session — and when the decision is made, composerID writes it back to the record it came from.
The widget sits on a topic page next to the Service Catalog and Knowledge Base — where requests already start. Employee Center runs on the Service Portal stack, so the widget is the embedding path, not an interim one.
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. Publishing the same decision twice updates that ticket instead of creating a second one.
ServiceNow is the only platform that is both a place requests start and a system composerID publishes into. ServiceNow developer notes → · ServiceNow as a destination →
A generic embeddable chat component for conversational surfaces. The same Intake Gateway renders Triage’s diagnostic as a turn-by-turn conversation, with locked answers and identical scoring guarantees.
The Chat Interface is a generic, embeddable chat component that renders Triage’s diagnostic as a turn-by-turn conversation. It embeds in messaging platforms, intranet portals, mobile apps and custom front-ends that support a chat widget.
Unlike the Teams 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. No platform SDK needed.
The Chat Interface connects to the same Intake Gateway as every other surface. The question order, the locked answers, the audit trail and the scoring are all enforced on the server. 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. From the minted Intent ID onward, it is standard composerID publishing.
Teams Adaptive Cards or Slack Block Kit - question, guidance, choices. Cards are updated in place and never deleted, so the thread shows what was asked and answered.
Verifies identity, renders questions, passes answers back and remembers where the conversation has reached. It works with any renderer.
The decision becomes an Intent Record with one traceable ID; composerID publishes it into the systems of record; publishing the same decision twice updates the same records instead of duplicating them.