> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflows on private incidents
> Automate response on private incidents, including granting team access and announcing them.
By default, workflows **don't run on [private incidents](/incidents/sensitive-incidents)**. Some steps could bypass the protections that keep them private, like emailing incident details to a mailing list or inviting people to the channel, so we hold workflows back unless you opt in.
## Run workflows on private incidents
To run a workflow against private incidents, open the workflow's **Advanced settings** and set **Run on private incidents**. You have three options:
* **No private incidents** (the default): the workflow only runs on public incidents.
* **Private incidents for owning teams**: the workflow also runs on any private incident that at least one of its [owning teams](/admin/restrict-workflow-management) can access. This follows each team's own access, not your team hierarchy, so a grant to a parent or child team doesn't count.
* **All private incidents**: the workflow runs on every incident, public and private.
A common use case is automatically granting access to private incidents. For example, you can add your security team to every private security incident, so the right people have visibility without manual invitation.
When a workflow runs on private incidents, the responsibility is on you to make sure it's safe and doesn't expose more
of the incident than you intend.
Running on private incidents needs the **Manage workflows that run on private incidents** permission. For **Private incidents for owning teams** you can hold it account-wide, or through a team role for every owning team. **All private incidents** always requires it account-wide. See [restricting workflow management](/admin/restrict-workflow-management).
## Steps that act on private incidents
Some steps are designed specifically for private incidents. On public incidents they do nothing, so the workflow needs **Run on private incidents** enabled to use them.
Because each of these steps widens who can see a private incident, **adding one to a workflow requires the matching permission to save the workflow**, on top of being able to edit workflows.
Adds a user as a member of a private incident, granting them access whether or not there's a channel. If there is a
channel, they're added to it.
Requires the **Manage private incident membership** permission.
Grants one or more teams visibility of a private incident. Members of the team can view the incident and join the
channel, but they're **not** added automatically. Useful for granting a team access based on incident conditions, like
giving your security team access to anything tagged as a security issue.
Requires the **Manage private incident team access** permission. See [confidential
incidents](/incidents/sensitive-incidents#set-default-team-access) for the other ways to set default team access.
Announces an incident in a Slack channel. By default it skips private incidents; turn on **Announce private
incidents** to include them. You can also choose how incident updates are shared once it's announced.
Requires the **Manage announcement rules for private incidents** permission. See [announcing private
incidents](/incidents/announcing-private-incidents).
## What people without permission see
Anyone can see a workflow that runs on private incidents, but only people with the right permission can change it. Without it, we show a banner explaining that the workflow runs on private incidents, and disable the actions to edit it.
## Related
* [Confidential incidents](/incidents/sensitive-incidents): make incidents private and manage access
* [Announcing private incidents](/incidents/announcing-private-incidents): announce private incidents safely
* [Workflows](/workflows): build and configure workflows