Skip to main content
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.
Prerequisites: a Security workspace with a public channel and an agent. On-call routing needs PagerDuty or incident.io connected. Device actions need an MDM.

​
What good looks like

1

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.
Learn more in Portal and privacy
2

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.

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.

Creating the ticket before the interview is the point. The report exists even if the reporter walks away mid-conversation.
3

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.
Learn more about emoji actions and channel ticket action settings
4

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:

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.

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

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.
Learn more about workflow triggers and actions
6

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.
Learn more about private tickets and private notes
7

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.
Learn more about tool execution policies
8

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.
Learn more in SLAs and business hours

​
Where teams get this wrong

Every barrier costs you reports, and the reports you lose are the embarrassing ones that matter most.
Ask for one thing. Interview afterwards.
Test for this before launch, not after.
Use the on-call schedule.
Use a 24-hour schedule for the top priority.

​
Next

Access reviews

The scheduled half of Security’s work.

Device lifecycle

Where the MDM tools are configured.
Last modified on September 17, 2026