> 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
Handle a set of related requests as one. Reply once and every requester gets the message in their own thread. Reassign, reprioritize, or resolve the whole group in a click
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.
* **Rollouts run from a script.** A laptop refresh generates eighty requests over a fortnight. A script groups them, moves the whole set to In Progress when the shipment leaves, and posts one message to everyone when it lands, without a person opening the group overlay.
### Create a Group Request
You create a group from the inbox, starting from requests that already exist.
{% stepper %}
{% step %}
### Select the requests
In the inbox list, tick the checkbox of each request you want to group. The bulk actions bar appears at the bottom of the list.
{% endstep %}
{% step %}
### Choose Group
Open the more options menu of the bulk actions bar and click `Group`, or press `W`.
{% endstep %}
{% step %}
### Name the group
In the `Create Group` window, enter a `Group name` and click `Group Requests`. The group replaces the selected requests in the list as a single row.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Grouping from the inbox combines existing requests; it does not create a child ticket under the original request. Workflows can also create a new group together with new requests, with the `Create a group` action.
{% endhint %}
### Create a group from a workflow
The `Create a group` action builds a named group and the requests inside it in one step. Use it when one event should fan out into a set of tickets that belong together: a starter who needs a laptop, app access, and a badge, or an office move that opens the same three requests per floor.
* Add between **1 and 20** child requests to the action. Each one is configured exactly like the single `Create a request` action, with the same fields and the same variable interpolation.
* The group name is a plain text field and takes variables too, so `Onboarding — {{user.first_name}}` names each group after the person it is for.
* The action is available on Request, People, Date, and App access workflows. Only People workflows can delay it; on every other trigger it runs immediately.
* Later steps can reference the group with `{{actions..requests_group_uid}}` and `{{actions..requests_group_name}}`.
* The group and its requests are created together. If any child fails, none of them are created and the workflow run reports the error against the step.
The workflow run history shows one result for the whole step, naming the group and every request in it.
### Add requests to an existing group
* From the inbox: select the requests, then click `Add to group request` in the bulk actions bar, or press `Shift + W`. Pick the group in the `Add to Group` window.
* From a request: open the `...` menu of the request and click `Add to group request`. The option only shows when the request is not already in a group.
* From the group: in the `Child requests` panel, click `+` (`Add Request`) and select the requests to add.
### 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 remove it whenever it 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.
* Remove a child: open the `...` menu of the child request, click `Dissociate`, then confirm with `Remove from group`. The request stops receiving broadcasts and returns to the list as a standalone.
* Ungroup: open `Group actions` in the group overlay, click `Ungroup`, then confirm. Every child becomes an independent request again. The option only shows when the group has several children; for a single remaining child, use `Dissociate`.
* 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).
### **Group Requests in the Public API and MCP**
A group behaves as one object outside the app too. The Public API returns a group alongside its member requests, and the Siit MCP server exposes matching tools, so a script, a Workflow, or an AI agent works on the group instead of iterating over the requests inside it.
Both surfaces cover the full set:
* **Group management**: create a group, add or remove requests, rename it, disband it, read it back, and list groups instead of individual requests.
* **Bulk actions**: send one public message, add one internal note, set status, priority or assignee, add tags, archive, and snooze. One call, every request in the group.
The behaviour matches the app. A bulk message reaches each requester in their own Slack thread, Microsoft Teams chat, or email, and the grouping stays invisible to them. Notes stay internal.
Bulk actions run with the permissions of the caller, so they only touch the requests that caller can already see. Each one records a single bulk event on the group timeline rather than one event per request, and returns a count of the requests it processed.
> **Note** - Bulk actions are not atomic. An individual request can be skipped, for example when it is not reachable, and the count tells you how many were processed, not how many requesters received the message. Check the group timeline for the detail.
See the [MCP](https://docs.siit.io/integrations/mcp) page for the full list of tools, and the [API reference](https://developer.siit.io/) for the matching endpoints.
---
# 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/group-requests.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.
