> ## 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. # Communications > Send targeted incident updates to the stakeholders who need them, by email, SMS, or Slack, from templates your team prepared in advance. The **Communications module** sends incident updates directly to the people who need them — by email, SMS, or Slack — rather than broadcasting to everyone. Responders pick a prepared template, the incident's details fill themselves in, and the message reaches only the stakeholder groups whose conditions the incident matches. It is the targeted counterpart to a [status page](/configuration/status-pages). A status page tells anyone who looks; Communications tells a specific audience, and can require review before anything goes out. Communications is enabled per organization. If the **Communications** tab does not appear on your incidents, contact your account team. *** ## Where to Start The responder flow: pick a template and stage, edit it, send it for review, and send it. Define who hears about what, and the conditions that decide when they do. Prepare the messages in advance, one per stage of an incident. The addresses and numbers your messages come from, and getting them allowlisted. *** ## The Moving Parts Four pieces fit together. Set them up in this order — each depends on the one before it: A category of communication, such as customer updates or internal leadership updates. Everything else hangs off a type: groups belong to one, and so do templates. The phases of an incident you communicate at — for example initial, investigating, resolved. Stages are shared across the organization. The prepared message for a type, with separate content per stage and per channel. Liquid variables pull in the incident's own details. Who receives a type of communication, and under what conditions — a severity, a service, a functionality, a team, or an incident type. With those in place, sending during an incident is a matter of choosing a template and a stage, checking the text, and sending. *** ## What a Responder Does During an incident, the **Communications** tab lists everything already sent, with its delivery status, and lets you create the next update. The same flow is available in Slack with `/rootly comms new`. Rootly suggests the template that fits the incident, and the recipients are worked out from the groups whose conditions the incident matches — so a responder is choosing what to say, not who to say it to. The decision about *who* hears about an incident belongs in your group conditions, made calmly in advance. Leaving it to the person writing an update at 3am is how the wrong stakeholders get paged, or the right ones get missed. *** ## Review Before Sending Any draft can be shared to a Slack channel for review before it goes out. The request is clearly marked as needing review, so approval happens where your team already works rather than in a separate tool. A sent communication cannot be recalled. For anything customer-facing, or anything a regulator or executive will read, route it through review — and remember that SMS in particular has no correction path once delivered. *** ## Best Practices * **Decide your audiences before your messages.** Groups and their conditions are the hard part; templates are easy once you know who is listening. * **Write one template per type, not per incident.** Stages handle the difference between "we're investigating" and "it's resolved". * **Use Liquid for anything factual.** Severity, title, summary, and timestamps should come from the incident record rather than being retyped under pressure. * **Make review the default for external audiences.** Internal updates can go direct; customer-facing ones benefit from a second reader. * **Allowlist Rootly's sending addresses and numbers early.** Discovering a spam filter mid-incident is an avoidable failure — see [Communication Sources](/communications/sources). * **Revisit conditions after reorganizations.** Groups scoped to services or teams drift when ownership changes. *** ## Related Resources Broadcast status publicly, for anyone who looks. Post incident updates to a status page. Every incident value a template can pull in. Automate notifications that do not need a human author. *** ## Frequently Asked Questions Reach and intent. A status page is public and passive — anyone can look, nobody is notified. Communications is targeted and active: it pushes a message by email, SMS, or Slack to defined groups. Most teams use both, with the status page as the public record and Communications for the audiences who need telling directly. A [workflow](/workflows/workflows) fires automatically with no author, which suits mechanical notifications. A communication is written or approved by a person, so it suits messages where the wording matters and someone should be accountable for it. Yes. Groups can contain external members, which is the point — customers, executives, and support leads generally are not Rootly users. Yes. Types, stages, templates, and groups all have Terraform resources. See [Terraform](/integrations/terraform).