> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/request-management/request-conversation.md).
# Request conversation
Every request has one timeline holding agent replies, internal notes, approvals, SLA updates, and workflow events. Messages sync to the requester's Slack or Teams thread and the Portal
Every request has a single conversation timeline that keeps the full story in one place—agent replies, internal notes, approvals, status/SLA updates, and workflow events. Messages sync to the requester’s original channel (Slack or Microsoft Teams) and to the Portal.
### What you can do in the request conversation
* Reply: send a public message to the requester in Slack/Teams and the Portal. Attach files, use @mentions, and preview before sending.
* Internal note: add private context for agents/admins only. Great for handoffs, troubleshooting, and coaching.
* Approval: request sign‑off from one or more approvers. Statuses (Pending, Approved, Rejected) are tracked in the timeline and the sidebar.
* Message Templates: insert reusable answers with variables to personalize at scale.
* Solve with Assist: hand the request to [Assist](/ai/assist.md), which proposes a resolution plan you apply or deny in one decision.
#### Message reply box
* Type selector (left): choose Reply, Internal note, or Approval.
* Composer: supports attachments, mentions, emojis, and templates.
* Preview: review before sending (public replies and approvals).
* Pinned actions: the composer shows a row of shortcuts — **Solve this request with Assist**, articles, files, emojis, and message templates. Open the **⋯** menu to run one that isn't pinned, or to pin and unpin them yourself.
#### [Solve this request with Assist](/ai/assist.md)
Click the Assist icon in the composer, or pick **Solve this request with Assist** from the **⋯** menu, and Assist opens on this request. It reads the request, then proposes a numbered **resolution plan**: every action that would change something, in the order it would run, often ending with a message to the requester that you can read before deciding.
**Apply** runs the whole plan, step by step, stopping at the first failure. **Deny** runs nothing and keeps the proposal in the conversation. Each step ends up labelled **Done**, **Denied**, **Failed**, **Not run**, or **Unconfirmed** for a step the run was interrupted on.
The option shows while the request is still open, and only for admins who can use Assist. See [Assist](/ai/assist.md) for the full behaviour.
#### Replies
* Channel aware: goes to the requester where they started (Slack/Teams), and to the Portal.
* Files: upload documents, images, or links; everything is mirrored to the request.
* Articles: access your entire knowledge base to share articles
* Mentions: @colleagues to bring them in; they become participants and get notified.
#### Internal notes
* Visibility: only agents/admins can see notes; requesters never do.
* Uses: capture investigation steps, share context across shifts, or coach teammates.
* Mentions: notify teammates without pinging the requester.
#### [Approvals](/request-management/approvals.md)
* How it works: pick approver(s), add context (or use a template), and send. Approvers can act from Slack/Teams or the Portal—no extra license needed.
* States: Pending → Approved/Rejected. All decisions are logged in the timeline with who, when, and any comment.
* Templates: prefill the message and include dynamic variables (approval\_link, requester.first\_name, app.name, etc.).
* Automate: trigger workflows on Approved/Rejected (e.g., change status, assign, kick off provisioning, notify requester).
#### [Message templates](/request-management/message-templates.md)
* Purpose: keep answers fast and consistent; update centrally when policy changes.
* Variables: personalize with fields like requester.first\_name, requester.manager, service.name, app.name, approval\_link, and more.
* Organization: group templates by team or service for easy discovery.
* Access: choose templates from the composer; admins manage them in Settings.
#### What happens automatically when you reply
Replying to a request also moves it along: it picks up an assignee, adds you as a follower, and shifts the status. Those four behaviours are now switches you control, in **Settings → Requests → Request behavior → Requests automations**.
| Setting | What it does |
| ------------------------------------------ | -------------------------------------------------------------------- |
| **Automatically assign me to the request** | Assigns the request to you when you send the first reply |
| **Automatic follow when reply** | Adds you as a follower when you reply |
| **Automatic follow when adding notes** | Adds you as a follower when you add an internal note |
| **Move to In progress when I first reply** | Moves an open request to `In progress` when you send the first reply |
All four are on, which is how Siit behaved before they became settings, so nothing changes until you turn one off. They apply to the whole workspace, not per admin.
Two rules still hold whatever you set: auto-assignment skips a request that already has an assignee, or one in an inbox you're not a member of, and the status move is skipped when an admin has already set the status by hand.
The switches live under **Request behavior**, alongside **Request on behalf** and **Satisfaction survey**. All three pages are covered by a single `Request behavior` permission — see [Roles & permissions](/workspace/roles-and-permissions.md).
#### [The side panel (Details)](/request-management/side-panel.md)
* Request details: status, assignee, service, priority, tags, SLA timers, Snooze/Resolve.
* People info: requester profile (title, manager, department, location, contacts).
* Integrations: quick actions to connected systems (e.g., Okta, Google/Azure, MDM) when available.
* Context: related requests, assigned equipment, active apps.
* Approvals: current approval(s) with state and actions.
* Deep links: clicking people, devices, or apps opens their dedicated pages for full context.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.siit.io/request-management/request-conversation.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
