> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Recipient Groups > Define who receives each type of incident communication, and the conditions that decide which incidents reach them. A **recipient group** is a list of people who should hear about a particular kind of incident, plus the conditions that decide which incidents qualify. Groups are what make communications targeted: a responder chooses the message, and the groups decide the audience. Getting groups right is the substantive work in setting up Communications. Templates are easy once you know who is listening. *** ## What a Group Holds What this audience is, in the terms your organization uses. "Enterprise customer success" beats "Group 2" when someone is checking who a message reached. Every group belongs to one [type](/communications/templates-and-stages#types). This is what connects an audience to the messages it can receive — a group under "Customer updates" only ever receives customer-update communications. Rootly users and external people. External members are the point of the feature: customers, executives, and support leads generally do not have Rootly accounts. A group holds up to 50 participants. How this group is reached. Match the channel to the audience rather than the message — executives may want SMS for severity 0 and email for everything else, which is two groups, not one. A **private** group is managed by admins: membership is deliberate. A **public** group can be subscribed to, so stakeholders opt themselves in. Public groups suit broad internal audiences; private groups suit anything external or sensitive. The 50-participant limit is per group, not per communication. A message reaching several matching groups reaches all of their members. Split large audiences by what they care about — which usually produces better-targeted conditions anyway. *** ## Conditions Conditions decide which incidents reach a group. Without them, a group would hear about everything. A condition matches an incident property against values you choose: | Property | Use it to reach people who care about… | | ----------------- | ------------------------------------------------------------------------------------------------------- | | **Severity** | Only serious incidents — the usual first condition for executive or customer audiences. | | **Service** | A specific system, for the team or customers who depend on it. | | **Functionality** | A user-facing capability, which often maps better to what customers recognize than a service name does. | | **Team** | Incidents owned by a particular team. | | **Incident type** | A class of incident, such as security. | ### All or Any A group matches on **all** of its conditions or **any** of them, and the difference is large: * **All** — every condition must match. `Severity is SEV0` *and* `Service is Payments` reaches this group only for severity-0 payments incidents. Narrow and predictable. * **Any** — one match is enough. The same two conditions now reach the group for *every* SEV0 anywhere, *and* every payments incident at any severity. Much broader than it looks when writing it. Setting a group to **any** with several conditions is the most common way stakeholders end up over-notified. Start with **all**, confirm the group is being reached when it should be, and widen only if it is missing incidents it should hear about. *** ## Public Groups and Self-Subscription A public group can be subscribed to rather than administered. This works well when the audience is large, internal, and self-selecting — the people who want to know about payments incidents usually know who they are. Keep external and sensitive audiences private. Anything a customer receives should have deliberate membership. Public groups reduce the maintenance burden that kills communication setups. A private group nobody updates after a reorganization quietly sends to the wrong people; a public one lets its members fix that themselves. *** ## Designing a Group Structure Groups multiply quickly. A structure that stays manageable usually follows the audience, not the org chart: 1. **Start from the question "who needs to know?"** for two or three realistic incidents. That produces your first groups. 2. **Separate by channel only when the channel genuinely differs.** An audience that wants SMS for severity 0 and email otherwise is two groups with different conditions. 3. **Prefer functionality over service for customer-facing groups.** Customers recognize "Checkout" more readily than the services behind it. 4. **Keep executive groups narrow.** A severity condition alone is usually right; adding services tends to produce gaps. 5. **Review after reorganizations.** Conditions referencing services or teams drift when ownership moves. *** ## Troubleshooting Check the incident against the group's conditions rather than the message. The usual causes: the incident's severity is below the threshold, the affected service or functionality is not attached to the incident, or the group's conditions are set to **all** and only some matched. Conditions are probably set to **any**. Switch to **all** and add the narrowing condition that was missing, most often severity. A group holds up to 50 participants. Split it along the lines its conditions already suggest — by service or functionality — rather than raising the count. Groups belong to a communication type, and a type in use cannot be removed while groups or templates depend on it. Detach or remove those first. The group is private. Only public groups accept self-subscription. *** ## Related Resources The messages these groups receive. How groups are resolved when an update goes out.