Student Restrictions

The Student Restrictions action on a workflow 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.

​

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, without any delay or human error.

​

How restrictions work

When an incident matches a workflow with a Student Restrictions 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.

​

Configuring the Student Restrictions action

When adding a Student Restrictions action to a workflow, you can choose:

• Specific staff members — exclude individual people from viewing
• Staff Groups — exclude everyone in one or more Staff Groups

​

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