> ## 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. # Sending a Communication > Create an incident update from a template, edit it with live incident detail, send it for review, and deliver it to the right stakeholders. During an incident, the **Communications** tab is where updates to stakeholders are written, reviewed, and sent. Everything already sent is listed there with its delivery status, so a responder joining late can see what has gone out before adding to it. The same flow is available in Slack with `/rootly comms new`, which matters when the incident is being run in a channel rather than in the web interface. *** ## Reviewing What Has Already Gone Out Before writing anything, check the record. The **Completed** list shows each communication that has been sent, and opening one shows: * Where it originated * Which recipient groups received it, including any Slack channels * Its delivery state — sent, partially sent, or still sending * Any drafts associated with it Read the last update before writing the next one. Stakeholder trust is lost faster by contradicting a previous message than by saying nothing, and the previous message is rarely the one you remember sending. *** ## Creating an Update Select **Create New** in the incident's Communications tab, or run `/rootly comms new` in Slack. Rootly suggests the template that fits the incident. Every available template is in the dropdown if the suggestion is not the right one. Stages represent where the incident has reached — an initial notification reads differently from a resolution notice. Selecting a stage loads that stage's prepared content. See [Templates and Stages](/communications/templates-and-stages). This opens the editor with the template rendered against the live incident. *** ## The Editor The editor shows the message alongside the facts about it. **On the left**, the details of the communication itself: its status, the type and template it came from, the stage, who created it, the addresses and numbers it will send from, and the recipient groups it will reach. **On the right**, the message. Template content arrives already filled in — Liquid variables have pulled the incident's title, summary, severity, and timestamps out of the record rather than asking you to retype them. Each channel is edited separately, so the email body, the SMS text, and the Slack message can each say what suits that medium. Editing here changes this message only; the template is untouched. SMS is capped near 160 characters, so the SMS version of an update is not a shortened email — it is a different message. Write it as a pointer: what is wrong, who is affected, and where to read more. *** ## Sending, Saving, or Requesting Review Three actions, and choosing between them is mostly about audience: Deliver now, to every group whose conditions the incident matches. Requires permission to send. There is no recall. Keep the message without sending. Useful when you have written an update ahead of a decision that has not been made yet, or when handing the incident to the next responder. Send the draft to a Slack channel or specific people for review. The request is clearly marked as needing review, so approvers see it as a task rather than another notification. *** ## Getting a Communication Reviewed Review exists because the cost of a wrong external message is much higher than the cost of a delayed one. Choose the channel or people who should read it. They see the message as recipients will. Discussion happens in Slack, next to the incident, rather than in a separate approval tool. Apply any changes in the editor, then send. The draft and the sent message both stay on the record. Review is worth its delay for anything customer-facing, anything a regulator or executive will read, and any message stating a cause or a restoration time. Internal "we are on it" updates rarely need it. *** ## Delivery Once sent, a communication moves through delivery rather than completing instantly. The Communications tab shows whether it is still sending, fully sent, or only partially delivered. Partial delivery usually means individual recipients failed rather than the message failing — a bounced address, an unreachable number. Check the affected recipients rather than resending to everyone, which would deliver the message twice to people who already have it. *** ## Troubleshooting Recipients come from group conditions, not from the message. If no group's conditions match this incident, there is nobody to send to. Check the incident's severity, service, functionality, team, and type against your [group conditions](/communications/recipient-groups#conditions). A group's conditions are broader than intended. Conditions can require all criteria to match or any of them — a group set to "any" reaches far more incidents than one set to "all". Almost always filtering rather than delivery. Confirm Rootly's sending addresses are allowlisted — see [Communication Sources](/communications/sources) — and check whether the recipient's provider quarantined it. A Liquid variable that does not resolve renders empty. Usually the field is genuinely blank on the incident — a summary that was never written, for instance. Fill it on the incident and recreate the communication. Sending is permission-gated. Save the draft and share it for preview so someone with permission can send it. *** ## Related Resources Why a given incident reaches a given audience. Prepare the messages this flow draws on.