Managing Incident Visibility

By default, every member of staff with the Contributor role or above can see the incidents recorded in Signal. (Staff with the Reporter role are an exception — they only ever see the concerns they recorded or were @mentioned in, whatever you do here.) For most concerns that is exactly what you want. But some cases are too sensitive for wide access — an allegation against a member of staff, a concern involving a colleague’s own child, or a highly sensitive disclosure. Signal gives you three distinct ways to control who can see what. They work at different levels, and you can combine them. This page explains each one, when to reach for it, and how to set it up.

​

The three controls at a glance

Use this table to decide which control fits:

---

​

1. Student restrictions

Student restrictions stop one individual staff member from seeing anything about a particular child. When you restrict a staff member from a student, that child’s profile, incidents, and documents all disappear for that person, and they stop receiving alerts about them. This is the right control when the sensitivity is tied to a person, not to the nature of a case. The classic example is a member of staff who is a relative of a child at the school — a parent, sibling, aunt, or uncle who works there. They should not be able to read that child’s safeguarding history through Signal, regardless of what the concerns are about. Restrictions are configured on the staff member’s page — not on the student’s profile. You choose the students that this particular member of staff should not be able to view. The Staff list shows a Restrictions column, so you can see at a glance who has restrictions in place and filter by it.

---

​

2. Workflow exclusions

A workflow watches for incidents that match criteria you define — a category, a location, a Staff Group, and so on. An Apply Exclusions action on a workflow automatically hides every matching incident from the staff you choose. Set the rule once, and it protects both existing and future incidents without anyone having to remember. This is the right control when the sensitivity is tied to the type of concern rather than a single record. For example, you might decide that every incident in a “Sensitive” category should only ever be visible to safeguarding leads.

​

How workflow exclusions behave

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 — the incident disappears from their lists, the student’s profile, and search.
3. Excluded staff see no indication the incident exists, protecting the case’s confidentiality.

The rule is checked live, every time an incident is viewed, so restrictions apply to all matching incidents — past and future:

• Creating or enabling a workflow immediately restricts every existing incident that matches it, including ones imported from a previous system.
• Disabling or deleting the workflow immediately restores visibility.
• If an incident’s categories change so it no longer matches, the restriction lifts automatically — and reapplies if it matches again.

​

Setting up an Apply Exclusions action

When you add an Apply Exclusions action to a workflow, choose one of:

• DSL Staff Only — hide matching incidents from everyone except DSLs, Deputy DSLs, and Owners. The simplest way to keep concerns visible to safeguarding leads only, without maintaining a Staff Group of everyone else.
• Staff Groups — exclude everyone in one or more Staff Groups.
• Individual Users — exclude named staff members.

For the full workflow setup, see Apply exclusions on a workflow.

---

​

3. Per-incident visibility

Sometimes a single incident needs to be held more tightly than everything around it. Manage Visibility on the incident lets you add manual exclusions to that one record, on top of whatever the workflow rules already apply. You can set visibility when you first record an incident, or edit it later from the incident detail view. The options mirror the workflow ones:

• DSL Staff Only — only DSLs, Deputy DSLs, and Owners can see the incident. All other staff are excluded.
• Exclude Staff Groups — choose entire Staff Groups to exclude.
• Exclude Users — choose individual staff members who should not see it.

​

Seeing who has been told

Manage Visibility opens the Incident Visibility dialog, which has two tabs. Who is hidden holds the exclusion settings above. Who was told lists everyone who has been notified about the incident, and whether they have opened it yet. Each row shows how the person was notified — Alerted by a workflow rule or a new comment, or Mentioned — along with the date, and either Opened or Not opened. A count at the top summarises how many notifications are still unopened. This answers a question exclusions cannot: it is obvious who has been @mentioned, but not who a workflow rule quietly alerted. Use it to check a concern actually reached the right people, and to follow up with anyone who has not opened it — either by prompting them in Signal, or by passing the message on in person.

​

How per-incident visibility works with workflows

If your school uses workflow exclusions, Manage Visibility shows what the workflow rules currently apply to this incident — read-only, so you can see exactly who is excluded today. To change those, edit the workflow itself. Your manual settings combine with the workflow rules: anyone hidden by either stays hidden. Manual exclusions can only ever narrow who sees an incident, never widen it — there is no way to exempt one incident from a workflow rule. Use Clear all to remove the manual settings again; the workflow rules are unaffected. If a member of staff you are excluding is already @mentioned on the incident, Signal warns you: a mention keeps the incident visible to that person regardless of exclusions. Remove the mention from the description or comment to take their access away.

---

​

How the three controls combine

You can use all three together. When Signal works out whether a member of staff can see a record, every applicable control is respected:

• A student restriction hides everything about that child from the restricted staff member — this always wins for that person.
• A workflow exclusion hides matching incidents from the staff it names — always, on every matching incident.
• A per-incident setting adds to the workflow rules for that one incident: anyone hidden by either stays hidden.
• An @mention opens that one incident to the mentioned person despite any exclusion — though never past a student restriction.
• Safeguarding leads (DSL, Deputy DSL, Owner) cannot be excluded from an individual incident, by either a workflow rule or a per-incident setting. A student restriction does bind them, so it is the one control that can hide a record from a DSL.
• Staff with the Reporter role start from a much narrower view — only what they recorded or were @mentioned in — and these controls narrow it further. Marking a Reporter’s own report DSL only, or excluding them from it, removes it from their view entirely. That is often the right call for a sensitive disclosure; just be aware the person who filed it will no longer be able to look it up.

​

Related pages