> ## Documentation Index
> Fetch the complete documentation index at: https://signalschools.co.uk/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Apply Exclusions
> Automatically restrict who can view sensitive incidents using workflow actions. Protect confidential cases by excluding specific staff or Staff Groups from seeing the incident.
The **Apply Exclusions** action on a [workflow](/docs/workflows/overview) automatically limits who can see an incident when it matches the workflow's trigger criteria. This is essential for sensitive categories where only certain staff should have access.
This is one of three ways to control who can see safeguarding records. For an overview of all three — student restrictions, workflow exclusions, and per-incident visibility — and how to choose between them, see [Managing incident visibility](/docs/incidents/managing-visibility).
## Why use restrictions
Some safeguarding concerns — such as allegations against staff, cases involving staff family members, or highly sensitive disclosures — need tighter access control than the default. Rather than relying on someone to manually restrict an incident after it is recorded, you can set up a workflow to do it automatically.
This ensures that sensitive incidents are protected from the moment they are created — and existing incidents that match the rule are protected too, without any delay or human error.
## How restrictions work
When an incident matches a workflow with an Apply Exclusions action:
1. Signal identifies the staff members or Staff Groups configured on the action
2. Those staff are **excluded** from viewing the incident
3. The restriction takes effect immediately — excluded staff cannot see the incident in lists, on student profiles, or through search
Staff who are excluded see no indication that the incident exists. This protects the confidentiality of the case.
Restrictions apply to **all matching incidents — past and future**. The rule is checked every time an incident is viewed, so:
* Creating or enabling a workflow immediately restricts every existing incident that matches it, including incidents imported from a previous system
* Disabling or deleting a workflow immediately restores visibility of those incidents
* If an incident's categories change so it no longer matches the workflow, the restriction lifts automatically — and reapplies if it matches again
DSLs, Deputy DSLs, and Owners always keep full visibility — workflow restrictions never apply to them.
## Configuring the Apply Exclusions action
When adding an Apply Exclusions action to a workflow, you can choose:
* **DSL Staff Only** — hide matching incidents from everyone except DSLs, Deputy DSLs, and Owners. This is the recommended setup for keeping safeguarding concerns visible to safeguarding leads only, without having to maintain a Staff Group of everyone else
* **Staff Groups** — exclude everyone in one or more Staff Groups
* **Individual Users** — exclude individual staff members from viewing
When DSL Staff Only is switched on, the Staff Group and user selections are not needed and are cleared. Switching it back off does not bring them back — you will need to select them again.
Be careful when configuring restrictions. Excluding too many staff can make it difficult to manage cases. Ensure that at least the relevant DSLs and senior leaders retain access.
## Example use cases
* **Sensitive disclosures** — restrict incidents in a "Sensitive" category so only the DSL and Head Teacher can see them
* **Staff-related concerns** — when a student incident involves a staff member's family, restrict viewing to senior leadership
* **Controlled information sharing** — limit who sees incidents involving students in specific vulnerability groups
## Overriding restrictions on a single incident
Sometimes one incident needs different visibility from what the workflow rules provide. Open the incident's **Manage Visibility** settings to take manual control:
1. The settings open pre-filled with what the workflow rules currently apply, so you can see exactly who is excluded today
2. Adjust the DSL Staff Only switch, Staff Groups, or individual staff as needed
3. Saving makes your settings **authoritative for this incident** — workflow rules no longer apply to it, even if the workflow changes later
This also works the other way: setting exclusions when you first record an incident makes those settings authoritative in the same way.
To hand control back to the workflow rules, open Manage Visibility again and choose **Reset to workflow rules**. The manual settings — including the DSL Staff Only switch — are removed and the workflow rules apply again immediately.
Reset removes every manual setting on the incident, so its visibility becomes whatever the workflow rules say. If no workflow rule matches the incident, resetting leaves it visible to all staff. The option only appears when a rule currently matches.
If an excluded member of staff needs access to one specific incident — for example, a pastoral lead who is directly involved in the case — **@mention them** in the incident description or a comment. Mentioning someone always makes that incident visible to them, without changing the workflow or the incident's visibility settings.