Skip to main content

​
Overview

Signal has five predefined roles that determine what users can do within the system. Each role is designed for specific staff responsibilities and provides appropriate access to safeguarding information and features based on a hierarchical permission structure.
Roles cannot be customized. This ensures consistent, secure access control across all Signal schools and simplifies compliance auditing.

​
The Five Roles

Owner

Complete system controlFull access to all features including tenant management, user administration, and the ability to assign the Owner role to others.

DSL

Designated Safeguarding LeadAccess to all safeguarding features including students and incidents. Same permissions as Deputy DSL in current implementation.

Deputy DSL

Deputy Designated Safeguarding LeadCan manage incidents, students, and perform safeguarding tasks including deletions and document management.

Admin

System AdministratorAccess to configuration, user management, categories, policies, and transfers, but limited safeguarding data management capabilities.

Viewer

Standard accessCan view and create incidents, view students, manage alerts, and complete assigned actions.

​
Owner

Who should have this role?

  • Headteacher or Principal
  • Senior leader with ultimate responsibility for the system
  • Account owner or primary system administrator

​
What Owners Can Do

Owners have unrestricted access to everything in Signal. This role should be very limited (typically 1-2 people maximum).
Complete tenant control:
  • Update tenant details (name, email, settings)
  • View all tenant members
  • Add members to the tenant
  • Remove members from the tenant
  • Update member roles (including assigning Owner role)
  • Access tenant-specific settings
Critical: Limit Owner accounts to 1-2 trusted senior staff members. This role can remove other users, change all settings, and delete any data. For most administrative tasks, the Admin role provides sufficient access.

​
DSL (Designated Safeguarding Lead)

Who should have this role?

  • Designated Safeguarding Lead (DSL)
  • Senior safeguarding staff who need full access to safeguarding features

​
What DSLs Can Do

In the current implementation, DSL has the same permissions as Deputy DSL. Both roles have full access to safeguarding features but cannot manage tenant members or update tenant settings.
Full incident management:
  • View all incidents with optional filtering
  • Create new incidents
  • Update incident details (narrative, categories, etc.)
  • Delete incidents and all associated data
  • Upload and delete documents on incidents
  • Manage incident exclusion settings
  • View incident relationships
  • Complete incident creation workflow

​
What DSLs Cannot Do

  • Cannot update tenant details
  • Cannot remove members from the tenant
  • Can view tenant members but with Admin-level access only
  • Cannot create, update, or delete students (requires Admin role)
  • Cannot manage categories (requires Admin role)
  • Cannot manage policies (requires Admin role)
  • Cannot manage transfers (requires Admin role)

​
Deputy DSL

Who should have this role?

  • Deputy Designated Safeguarding Leads (DDSLs)
  • Senior safeguarding team members
  • Staff who need full safeguarding access but not administrative privileges

​
What Deputy DSLs Can Do

Deputy DSL has identical permissions to DSL in the current implementation. This role provides comprehensive safeguarding capabilities without access to system configuration or user management.
All capabilities listed under the DSL role apply equally to Deputy DSL. These roles are treated identically in the permission system, though they may differ in organizational hierarchy.

​
Admin

Who should have this role?

  • Business managers
  • School administrators
  • IT staff managing integrations
  • Senior leaders responsible for system configuration

​
What Admins Can Do

Manage tenant members:
  • View all tenant members
  • Add new members to the tenant
  • Update member roles (cannot assign Owner role)
  • Access tenant details and settings

​
What Admins Cannot Do

  • Cannot delete incidents (requires Deputy DSL or higher)
  • Cannot delete action records (requires Deputy DSL or higher)
  • Cannot manage incident exclusion settings (requires Deputy DSL or higher)
  • Cannot update tenant details (requires Owner)
  • Cannot remove members from the tenant (requires Owner)
  • Cannot assign the Owner role to users (requires Owner)
  • Cannot generate AI action recommendations (requires Deputy DSL or higher)
  • Limited access to specialized safeguarding document management
The Admin role is focused on configuration and user management rather than day-to-day safeguarding work. For staff who need both administrative and safeguarding capabilities, consider assigning both Admin and DSL/Deputy DSL roles.

​
Viewer

Who should have this role?

  • Teachers and form tutors
  • Teaching assistants
  • Pastoral support staff
  • Attendance officers
  • SENCOs and inclusion staff
  • Any staff member who records safeguarding concerns

​
What Viewers Can Do

Despite the name “Viewer,” this role has substantial read and write access to safeguarding features. It is the standard role for most staff members.
Create and manage incidents:
  • View all incidents with optional filtering
  • Get specific incident details
  • Create new incidents
  • Update incident details (narrative, categories, etc.)
  • Upload documents to incidents
  • Complete incident creation workflow
  • View incident relationships
  • View users visible to incidents

​
What Viewers Cannot Do

  • Cannot delete incidents (requires Deputy DSL or higher)
  • Cannot delete students (requires Admin or Owner)
  • Cannot delete actions (requires Deputy DSL or higher)
  • Cannot delete documents from incidents or students
  • Cannot create new actions (requires Deputy DSL or higher)
  • Cannot update action details (requires Deputy DSL or higher)
  • Cannot generate AI action recommendations (requires Deputy DSL or higher)
  • Can only complete actions, not manage them
  • Cannot manage categories, policies, or system settings (requires Admin or higher)
  • Cannot manage transfers (requires Admin or higher)
  • Cannot manage users or tenant settings (requires Admin or higher)
  • Cannot create new students (requires Admin or higher)
  • Cannot update student details (requires Admin or higher)
  • Cannot assign student groups (requires Admin or higher)
The Viewer role can create and edit incidents, which is different from traditional “read-only” access. This role is designed for staff who need to record safeguarding concerns but should not manage system configuration or delete records.

​
Permissions Comparison Matrix

Here’s a complete reference showing what each role can do:
FeatureViewerAdminDeputy DSLDSLOwner
Incidents
View incidents✅✅✅✅✅
Create incidents✅✅✅✅✅
Edit incidents✅✅✅✅✅
Delete incidents❌❌✅✅✅
Upload documents to incidents✅✅✅✅✅
Delete incident documents❌❌✅✅✅
Manage incident exclusions❌❌✅✅✅
Actions
View actions✅✅✅✅✅
Complete assigned actions✅✅✅✅✅
Create actions❌❌✅✅✅
Update actions❌❌✅✅✅
Delete actions❌❌✅✅✅
Generate AI action recommendations❌❌✅✅✅
Students
View students✅✅✅✅✅
View student timelines✅✅✅✅✅
View student attendance✅✅✅✅✅
Create students❌✅❌❌✅
Update student details❌✅❌❌✅
Delete students❌✅❌❌✅
Assign student groups❌✅❌❌✅
Upload student documents❌❌✅✅✅
Delete student documents❌❌✅✅✅
Alerts
View alerts✅✅✅✅✅
Mark alerts as read✅✅✅✅✅
Get unread count✅✅✅✅✅
Mark all alerts as read✅✅✅✅✅
Categories
View categories✅✅✅✅✅
Update category structure❌✅❌❌✅
Update category field configurations❌✅❌❌✅
Policies
View policies✅✅✅✅✅
Create policies❌✅❌❌✅
Update policies❌✅❌❌✅
Delete policies❌✅❌❌✅
Analyze policy URLs❌✅❌❌✅
Transfers
View transfers❌✅❌❌✅
Approve transfers❌✅❌❌✅
Reject transfers❌✅❌❌✅
Send transfers❌✅❌❌✅
Delete transfers❌✅❌❌✅
User Management
View tenant members❌✅❌❌✅
Add tenant members❌✅❌❌✅
Update member roles❌✅❌❌✅
Remove members❌❌❌❌✅
Tenant Settings
View tenant settings✅✅✅✅✅
View tenant details❌✅❌❌✅
Update tenant details❌❌❌❌✅
Legend: ✅ = Full access, ❌ = No access

​
Understanding the Role Hierarchy

Signal uses a hierarchical authorization model where policies grant access based on role privilege levels:
1

Owner Policy

Only Owner role can access Owner-restricted endpoints (tenant updates, member removal).
2

DSL Policy

Both Owner and DSL roles can access DSL-restricted endpoints. Currently, no endpoints use DSL-only restrictions.
3

Deputy DSL Policy

Owner, DSL, and Deputy DSL roles can access Deputy DSL-restricted endpoints (incident/action deletions, document management).
4

Admin Policy

Owner, DSL, Deputy DSL, and Admin roles can access Admin-restricted endpoints (user management, categories, policies, transfers).
5

Viewer Policy

All roles (Owner, DSL, Deputy DSL, Admin, and Viewer) can access Viewer-restricted endpoints (viewing/creating incidents, managing alerts).
This means that higher-privilege roles automatically inherit all permissions from lower-privilege roles. An Owner can do everything an Admin can do, plus Owner-specific tasks.

​
The Member Role

In addition to the five active roles, Signal has a special Member role:

Member (System Role)

Purpose: Default placeholder role for new tenant members who haven’t been assigned an active role yet.Behavior: Users with only the Member role cannot log in to Signal. They appear in the tenant member list but cannot access any features.Usage: When a user is added to a tenant, they initially receive the Member role. An Admin or Owner must then assign them one of the five active roles (Owner, DSL, Deputy DSL, Admin, or Viewer) before they can use the system.
The Member role is not selectable in the UI and does not appear in role dropdowns. It exists solely as a system placeholder to ensure new users don’t accidentally have access before proper role assignment.

​
Choosing the Right Role

1

Identify the user's primary responsibility

What will they do in Signal? Record concerns (Viewer), manage safeguarding cases (DSL/Deputy DSL), configure the system (Admin), or control the tenant (Owner)?
2

Apply the principle of least privilege

Give users the minimum access they need to do their job effectively. Most staff should be Viewers.
3

Consider role combinations

Users can have multiple roles. A business manager might have both Admin (for configuration) and Viewer (for incident access) roles.
4

Limit high-privilege roles

Owner should be 1-2 people maximum. DSL/Deputy DSL should be limited to your actual safeguarding leads. Admin should be limited to senior staff who manage the system.
5

Review regularly

Audit role assignments termly. When staff change responsibilities, update their roles accordingly.

​
Common Role Assignments

Typical setup for a 1-form entry primary (200-300 pupils):
  • Owner (1): Headteacher
  • DSL (1): Designated Safeguarding Lead
  • Deputy DSL (1-2): Deputy DSLs
  • Admin (1-2): Business Manager, Senior Admin
  • Viewer (15-25): All teaching staff, TAs, pastoral staff, attendance officer
Rationale: One Owner for ultimate control, safeguarding leads manage cases, Admin handles configuration, and most staff record concerns as Viewers.

​
Changing a User’s Role

Only users with the Admin role or higher can change user roles (Owner, DSL, Deputy DSL, or Admin).
Only Owners can assign or remove the Owner role. Admins can assign all other roles (DSL, Deputy DSL, Admin, Viewer) but cannot create new Owners.
1

Navigate to Users

Go to Settings → Users in Signal.
2

Find the user

Search for the user by name or email in the tenant members list.
3

Edit the user

Click on the user to open their details, then click Edit Roles.
4

Select new role(s)

Choose the role(s) from the available options. Users can have multiple roles.
5

Save changes

Click Save. The user’s roles will be updated immediately.
Role changes take effect immediately. If a user is currently logged in, they may need to refresh their browser or log in again to see updated permissions.

​
Best Practices

Only 1-2 people should have Owner access. This role can remove other users and change all tenant settings. For most tasks, Admin is sufficient.
These roles can delete incidents and manage sensitive safeguarding data. Only assign them to staff with formal safeguarding lead responsibilities.
Business managers, IT staff, and data managers who configure the system but don’t manage safeguarding cases should have the Admin role.
The Viewer role is appropriate for teachers, TAs, pastoral staff, and anyone who needs to record safeguarding concerns but not manage system configuration.
A user can have multiple roles. For example, a business manager who also records incidents might have both Admin and Viewer roles.
At least once per term, audit who has which roles. Remove high-privilege roles from staff who no longer need them.
Keep a record of why specific users have specific roles. This demonstrates appropriate access controls during inspections.

​
Troubleshooting

Check: Does the user have only the Member role?Solution: Assign them one of the five active roles (Owner, DSL, Deputy DSL, Admin, or Viewer). Users with only Member cannot log in.
Issue: Viewers cannot delete incidents. Only Deputy DSL and higher can delete.Solutions:
  • Have a DSL or Deputy DSL delete the incident for them (recommended for one-time needs)
  • If they regularly need to delete incidents, assign them the Deputy DSL role
Issue: Admins can configure the system but cannot delete safeguarding records.Solution: Assign them the Deputy DSL role in addition to Admin. They’ll retain Admin configuration access and gain safeguarding deletion permissions.
Example: “We want a role between Viewer and Deputy DSL that can create actions but not delete incidents”Explanation: Signal’s five roles cannot be customized. The permission structure is hierarchical and fixed to ensure consistent access control.Workaround: Choose the role that best matches the user’s primary responsibility. Consider using multiple roles if they need a combination of permissions from different levels.
Issue: Student creation and transfer management are both Admin-level permissions.Solution: Assign the Admin role. While they’ll have access to transfers, their actual usage can be monitored through audit logs. This is an intentional bundling of configuration capabilities.

​
Technical Notes

For developers and technical administrators: Signal’s authorization system uses policy-based authorization with hierarchical role requirements. Each policy (Owner, DSL, Deputy DSL, Admin, Viewer) allows access to users with that role or higher privilege. This is implemented in the IdentityServiceExtensions policy configuration.

​
Need Help?

If you have questions about role assignments or need support with user management, please contact: Support: support@signalschools.co.uk

​
Next Steps

Add Users

Learn how to add users and assign them roles

User Groups

Configure user groups to control student access

Users Overview

Return to the Users & Permissions overview

Get Support

Contact support for help with user access