Can we make it mandatory to enter affected pupils when recording peer on peer abuse?

Q: Can we make it mandatory to enter affected pupils when recording peer on peer abuse?

Sleuth is intended to be used to capture as much about an event as you know at the time of recording. You may not always know the names of all those affected at the time of initial recording (e.g. the event involved cyber abuse or the affected person is not on the school register). Rather than delay or prevent an event being recorded because 'mandatory' data is not known, the recommended steps would be to record and save all details you have certainty about and then update the event with further details as they become known. Another recommendation for significant incidents would be to include an auto-action in Sleuth so that a Sign-off or Quality Assurance action is automatically added to certain events which will ensure a designated staff member is actioned to review recorded details for completeness and ensure your post-incident protocol has been followed.

Webinar Q&A: Peer on Peer Abuse | Sleuth – Tracking Behaviour and Personal Development

Thank you for attending the recent webinar discussing how to track Peer on Peer Abuse in Sleuth. Below are answers to some of the questions asked by attendees.

Sleuth is intended to be used to capture as much about an event as you know at the time of recording. You may not always know the names of all those affected at the time of initial recording (e.g. the event involved cyber abuse or the affected person is not on the school register). Rather than delay or prevent an event being recorded because ‘mandatory’ data is not known, the recommended steps would be to record and save all details you have certainty about and then update the event with further details as they become known. Another recommendation for significant incidents would be to include an auto-action in Sleuth so that a Sign-off or Quality Assurance action is automatically added to certain events which will ensure a designated staff member is actioned to review recorded details for completeness and ensure your post-incident protocol has been followed.

As an admin user, from the menu select Admin Pastoral Settings and choose Negative* Behaviour Groups. You can select an existing group or click the button in the toolbar to add a new one. Then simply click the behaviours on the click-pad to select those that you want to appear in this behaviour group. Note that the sort code for the behaviour group determines the order of the tabs (left to right) for data entry and the sort order for the behaviour determines the order of behaviours on the click-pad (left to right).

* The event category description can be customised so in your school this might be labelled Incident rather than Negative

Yes, the use of a Status is optional for the different event types in Sleuth. You can also control which users are able to enter/update the status for a particular event type. This is setup from the menu in Admin Settings School where you will find Event Types and Event Status. Any of the status you wish to use for an event can have an action linked to it that will automatically be assigned when the status is set or updated. This can be used to ensure certain actions are recorded when particular events are created and/or their status is updated. A typical application of this would be to include an auto-action that alerts a particular staff team – for example, the medical team when an injury has occured, SLT if restraint has been used or the DSLs when a concern is raised.

This video below describes how to set-up Concerns to use the Status field to trigger an auto-action:

Yes, a Sleuth Admin user (with additional permissions, see below) can update a description of a behaviour, however rather than changing the descriptor there is another option to consider here. If the new description also changes the meaning of the behaviour, even if this is only subtle, we would recommend ‘retiring’ the ‘Victim’ behaviour from use by unchecking the Show in Lists checkbox and creating a new behaviour called Affected. This is because a change to the description will update all previously recorded events where it has been used and potentially change what the reporter intended. Hence, even an Admin user will require additional permissions (given using the User Permission menu option) to change some record descriptors in Sleuth. This extra layer of security is to preserve the integrity of data and prevent accidental changes that will update your event data history in Sleuth.

If you have questions that aren’t included here, the new Inline Sleuth help system is a great place to look for videos and articles (just click the blue Help button when you are logged into Sleuth) or contact us and the one of the Support/Advisory team will get back to you.