> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Incident intake

> Build a reporting path people actually use: a public channel, a one-field report, emoji reporting, on-call-aware escalation, and private investigation once it lands.

export const Checkbox = ({items = []}) => {
  const [checked, setChecked] = useState(Array(items.length).fill(false));
  const toggle = index => {
    setChecked(prev => {
      const copy = [...prev];
      copy[index] = !copy[index];
      return copy;
    });
  };
  return <div className="custom-checkbox-list">
      {items.map((text, index) => <div key={index} className="custom-checkbox-item flex items-center mb-2">
          <input type="checkbox" checked={checked[index]} onChange={() => toggle(index)} className="mr-2" />
          <span>{text}</span>
        </div>)}
    </div>;
};

Every minute between "I think something is wrong" and a filed report is a minute an attacker has. This playbook optimizes for one thing: making reporting the lowest-friction option available.

<Info icon="list-check">
  **Prerequisites:** a Security workspace with a public channel and an agent. On-call routing needs [PagerDuty](/integrations/pagerduty/overview) or [incident.io](/integrations/incident-io/overview) connected. Device actions need an MDM.
</Info>

## What good looks like

<Checkbox
  items={[
"Reporting takes one message, with no form to find and no permission to request",
"Nobody hesitates because they are not sure it counts",
"An escalation reaches whoever is on call right now, not whoever was named in the workflow",
"The investigation is private, while the reporting channel stays open"
]}
/>

<Steps>
  <Step title="Make the reporting channel public">
    `#security` should be a public channel that anybody can post in. This is the single most important decision on the page and the one most often made the other way.

    A private Security workspace is the right default for the *investigation*, and you can have both: keep the workspace private so non-members cannot browse tickets, and keep the intake channel open so filing is frictionless.

    <Callout icon="link" color="#6B7280">Learn more in [Portal and privacy](/guides/best-practices/portal-and-privacy)</Callout>
  </Step>

  <Step title="Ask for one thing, then let the agent ask the rest">
    A five-field incident form is a five-field reason not to report. Make the form's only required field a description, then let the agent collect the details conversationally once the report exists.

    <Prompt description="When someone reports a suspicious message, a lost device, or possible unauthorized access, create the ticket first, before asking anything. Then ask for what is missing, one item at a time: when it happened, what they clicked or entered, and the device involved. Tell them Security has been notified.">
      When someone reports a suspicious message, a lost device, or possible unauthorized access, create the ticket first, before asking anything. Then ask for what is missing, one item at a time: when it happened, what they clicked or entered, and the device involved. Tell them Security has been notified.
    </Prompt>

    Creating the ticket before the interview is the point. The report exists even if the reporter walks away mid-conversation.
  </Step>

  <Step title="Turn on emoji reporting">
    In channels Ravenna is connected to, reacting to a message with 🎫 creates a ticket from it. For a suspicious message posted in a Slack channel, that is a one-click report with the original message attached.

    Turn on **Public emoji actions** on the channel so non-members can trigger it too. Without that, every action is members only, which excludes exactly the people you need reporting.

    <Callout icon="link" color="#6B7280">Learn more about [emoji actions](/integrations/slack/emoji-actions) and [channel ticket action settings](/documentation/tickets/channels)</Callout>
  </Step>

  <Step title="Never let the agent give reassurance">
    This is the failure mode that matters. An agent that says "that link looks fine" has done more damage than one that says nothing.

    Put the limit in the custom prompt as a global boundary, not in a rule:

    <Prompt description="You answer security policy questions from the knowledge base: what to report, how to report it, the password and MFA policy, and which tools are approved. You never assess whether a specific message, link, file, or sender is malicious or safe, and you never tell a reporter that something is not a problem. Every report of a suspicious message, a lost device, or possible unauthorized access becomes a ticket.">
      You answer security policy questions from the knowledge base: what to report, how to report it, the password and MFA policy, and which tools are approved. You never assess whether a specific message, link, file, or sender is malicious or safe, and you never tell a reporter that something is not a problem. Every report of a suspicious message, a lost device, or possible unauthorized access becomes a ticket.
    </Prompt>

    Then test for it deliberately in testing mode. Send the agent a plausible-looking phishing message and confirm it escalates rather than opines.

    <Callout icon="link" color="#6B7280">Learn more in [writing agent rules](/guides/best-practices/writing-agent-rules)</Callout>
  </Step>

  <Step title="Escalate to whoever is on call now">
    A workflow that pages a named person is wrong within a quarter. Both on-call integrations query live schedule data on every run and match users by email, so the workflow asks who is on call at the moment it fires.

    The pattern:

    1. Trigger on ticket created in the Security channel
    2. Branch on severity, from the form field or a tag the agent applies
    3. For high severity, look up the current on-call responder and assign the ticket to them
    4. Post to the triage channel and notify the responder
    5. If the lookup returns nobody, fall back to the Security group rather than leaving it unassigned

    Step 5 is the one people skip. An unresolved on-call lookup that leaves a ticket unassigned is worse than no automation.

    <Callout icon="link" color="#6B7280">Learn more about [workflow triggers and actions](/documentation/automate/workflows/triggers-actions)</Callout>
  </Step>

  <Step title="Make the ticket private once it is real">
    A confirmed incident should not be readable by the company. Marking the ticket private restricts it to workspace members, which lets you keep the intake channel public while the investigation is not.

    Be precise about what this gives you: every member of the Security workspace can see every private ticket in it. For an investigation that needs a smaller audience than the whole Security team, use a separate workspace with a smaller membership.

    <Callout icon="link" color="#6B7280">Learn more about [private tickets](/documentation/tickets/private-tickets) and [private notes](/documentation/tickets/private-notes)</Callout>
  </Step>

  <Step title="Gate the destructive responses">
    Remote wipe, device retire, and disk encryption key retrieval are exactly the tools to put behind **Requires approval** rather than **Auto-execute**, even during an incident. Approval in Slack takes seconds, and an agent misreading an instruction does not.

    Keep the read-only lookups on auto-execute: device compliance state, encryption status, last check-in, group membership, MFA state. Those are what actually speed up a response.

    <Callout icon="link" color="#6B7280">Learn more about [tool execution policies](/documentation/automate/agents/configure#tool-execution-policies)</Callout>
  </Step>

  <Step title="Measure reports, not incidents">
    Report volume going up is a good sign in the first quarter. It means people trust the channel. Track it explicitly so nobody reads it as the environment getting worse.

    Also watch time to first response on high-severity tickets, and set the SLA against a 24-hour schedule rather than business hours. Attackers do not observe your working week.

    <Callout icon="link" color="#6B7280">Learn more in [SLAs and business hours](/guides/playbooks/slas-and-business-hours)</Callout>
  </Step>
</Steps>

## Where teams get this wrong

<AccordionGroup>
  <Accordion title="A private reporting channel">
    Every barrier costs you reports, and the reports you lose are the embarrassing ones that matter most.
  </Accordion>

  <Accordion title="A long intake form">
    Ask for one thing. Interview afterwards.
  </Accordion>

  <Accordion title="An agent that reassures">
    Test for this before launch, not after.
  </Accordion>

  <Accordion title="Paging a named person">
    Use the on-call schedule.
  </Accordion>

  <Accordion title="Business-hours SLAs on high severity">
    Use a 24-hour schedule for the top priority.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Access reviews" icon="shield-check" href="/guides/playbooks/security/access-reviews" horizontal>
    The scheduled half of Security's work.
  </Card>

  <Card title="Device lifecycle" icon="laptop" href="/guides/playbooks/it/device-lifecycle" horizontal>
    Where the MDM tools are configured.
  </Card>
</CardGroup>


## Related topics

- [Security](/guides/playbooks/security/overview.md)
- [Playbooks](/guides/playbooks/overview.md)
- [Guides](/guides/overview.md)
- [Workflows](/integrations/slack/workflows.md)
- [Employee onboarding](/guides/playbooks/hr/employee-onboarding.md)