> 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/group-requests.md). # Group Requests Group Requests let you handle a set of related requests as one. Reply once and the message reaches every requester in their own thread. Reassign or change priority on the group and Siit applies the update to every request inside it.
### Why Group Requests matter * One reply, many requesters: answer an outage, an office closure, or a policy change once and every affected requester gets the update. * One coordinated action: reassign, reprioritize, resolve, snooze, tag, or change service across the whole group in a single click. * One shared timeline: the full activity from every request inside the group, in chronological order, for clean handoffs and post-mortems. * No extra work for requesters: each person keeps a normal one-to-one conversation in Slack, Microsoft Teams, the portal, or email. ### Common use cases * **Incident management.** Slack goes down and 40 people report it within ten minutes. Group every "is Slack broken?" request, post one status update, and resolve them all together once the service is back. Each requester gets the all-clear in their own thread. * **Duplicate requests.** Three people in the Paris office submit the same "printer offline" ticket within an hour. Group them, answer once, and avoid three agents picking up three copies of the same problem. * **Onboarding or offboarding cohorts.** Five new hires start the same Monday and each one submits requests for laptop setup, app access, and badge issuance. Group the related requests by stage and run the same key actions across the cohort instead of jumping between fifteen tickets. * **Company-wide announcements that generate requests.** A tool migration, a security policy update, or a return-to-office change triggers a wave of related questions. Group them under one coordination thread, broadcast the official answer, and tag them for reporting. * **App rollout to a department.** A new design tool ships to the marketing team and twelve access requests arrive in the same hour. Group them, run a single approval thread with the app owner, and provision in one go. * **Recurring same-shape tickets.** Quarterly access reviews, monthly equipment swaps, or any wave of look-alike requests that benefit from a single coordinated pass rather than individual handling. ### How they show up in your inbox A Group Request appears in the list as a single stacked row with the `Group request` channel. The row aggregates its children: multiple requesters, the most recent activity time, and an unread state that lights up when any child is unread. * Stacked layout: one row per group, not one row per child. Children stop appearing on their own as long as they belong to a group. * Multi-requester display: the row shows every requester behind the group, not just one. * Live freshness: the group bubbles up the moment any child receives a reply, an action, or a workflow event. * Filter aware: any view that would match a child shows the group. Filter by priority, assignee, service, or tag and the group appears if any child matches.
### What you do from the group view The Group Request opens in a dedicated overlay built for coordinating across requests, not for a single conversation. You broadcast messages and run actions from one place and Siit fans them out to every child. * Bulk reply: send a public message and every requester sees it as a normal answer in their own channel. * Bulk internal note: capture investigation context across every child at once, agents only. * Key actions: change `Assignee`, `Priority`, or `Service` on the group and every child updates together. * Other bulk actions: `Resolve all`, change status, add or remove tags, snooze. Siit reports partial outcomes when a child cannot accept the action. * Message templates: the same templates you use on a single request work in the group composer. ### Operate on individual children Each child request keeps its own identity inside the group. Open any child from the group view, navigate between siblings, and unlink whenever a request no longer belongs. * Child overlay: open a child on top of the group to read the full request, see the sidebar, and run single-request actions. * Navigate between children: jump from one child to the next without leaving the group. * Unlink a child: removing a child stops the broadcast for that request and returns it to the list as a standalone. * Automatic cleanup: when the last child leaves, Siit deletes the empty group.
### Transparent to requesters Grouping is an admin construct. Each requester sees a standard request in their original channel, with their own private thread, their own status updates, and their own SLA. The fact that several requests share a group is invisible to them, so a broadcast reply reads exactly like a one-to-one answer. ### Where Group Requests fit Group Requests build on the primitives in [Request conversation](https://docs.siit.io/request-management/request-conversation) and reuse the same reply, note, approval, and template mechanics across many requests at once. The group surfaces in [Views](https://docs.siit.io/request-management/views) and respects the same filters and sharing rules. Group-level changes to assignee and priority follow the rules in [Assignment](https://docs.siit.io/request-management/assignment), and tag and SLA behavior on each child stays as documented in [Tags](https://docs.siit.io/request-management/tags) and [SLAs](https://docs.siit.io/service-catalog/slas). --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.siit.io/request-management/group-requests.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.