New article
Recently updated
Managing role-based access
Who is this article for?
Administrators responsible for configuring user access and permissions in SafetyStratus.
Administrator role required.
Role-based access in the SafetyStratus Incident Module ensures users only see and interact with incidents relevant to their responsibilities, maintaining security, clarity, and compliance.
1. Understanding role-based access
Role-based access means users only see and do what they need to, based on their role in the system. As an administrator, you decide who gets access to what by creating custom access roles such as Viewer, Reporter, Investigator, or Manager that fit your organization. Each role comes with different permissions, like viewing incidents, submitting reports, editing details, or closing investigations.
Role-based access provides several benefits:
- Keeps data secure – people only see the incidents they need to
- Reduces confusion – users have a clear view of their tasks
- Supports compliance – helps ensure the right people are involved in reviews and approvals
- Improves workflow – automatically routes tasks to the right roles
Role-based access gives the right people the right tools so everyone can focus on what they need to do.
2. Configuring access roles for the Incident Module
To configure access roles so the right people can interact with the right types of incidents, follow these steps:
- Go to Data Manager, then select Access Roles.
- Click the Create New Access Role button.
- Enter a name and description for your new access role.
- Set the status to Active, Inactive, or Archived.
- Choose Incident Module as the site module for this role.
- Select which incident type(s) this role should access, such as injuries, spills, or near-misses.
- Decide what this role can do with incidents by selecting from: Create, Open, Close, and View.
- Choose how this role's access should be filtered from options including Room, Group, Organization, Department, Facility, or Location.
- Go to the incident form by selecting Edit Forms.
- Find the question that controls access, such as "What department was involved?"
- Ensure the Defines Access Role Permission box is checked for that question.
- Go to the Edit Incident section.
- Edit the incident type.
- Assign the access role you created.
- Assign the form question that defines access.
Note: The access filter options (Room, Group, Organization, etc.) must be set up in the incident form for access control to work properly. The final step links your role to the right incidents and ensures the correct data fields appear based on the user's role.
3. Understanding permission combinations
Different combinations of Create, Open, Close, and View permissions determine what users can do with incidents. The following table shows how each combination affects user access:
| # | Create | Open | Close | View | What This Access Allows |
| 1 | ✅ | ❌ | ❌ | ❌ | Makes the New Incident menu link available. Can submit new incidents for that type and view or edit only the ones they created, both open and closed. |
| 2 | ❌ | ✅ | ❌ | ❌ | Can submit new incidents for that type and view their own and edit open incidents they have permission for. |
| 3 | ❌ | ❌ | ✅ | ❌ | Can submit new incidents for that type and view or edit the open ones they created and see closed incidents from allowed access role permissions. |
| 4 | ❌ | ❌ | ❌ | ✅ | Can submit new incidents for that type and view or edit only the ones they created, both open and closed. |
| 5 | ✅ | ✅ | ❌ | ❌ | Makes the New Incident menu link available. Can create new incidents and edit open ones they are assigned to, but no access to closed incidents outside of their own. |
| 6 | ✅ | ❌ | ✅ | ❌ | Makes the New Incident menu link available. Can submit new incidents and see closed ones from allowed areas (helpful for reviewing or exporting) and their own. |
| 7 | ✅ | ❌ | ❌ | ✅ | Makes the New Incident menu link available. Basic access role to create and view—they can submit and see or edit their own, but nothing else. |
| 8 | ❌ | ✅ | ✅ | ❌ | Can edit open incidents and view closed incidents they have access to, plus their own. |
| 9 | ❌ | ✅ | ❌ | ✅ | Can view or edit their own and edit open incidents from their assigned areas, with no closed incident access. |
| 10 | ❌ | ❌ | ✅ | ✅ | No view or edit of open items from others but can see closed incidents (with export) based on access group. |
| 11 | ✅ | ✅ | ✅ | ❌ | Power user: can do everything—submit, edit, view open and closed—based on location or group access. |
| 12 | ✅ | ✅ | ❌ | ✅ | Can submit and edit open incidents they are assigned to plus view their own, with no access to closed incidents submitted by others. |
| 13 | ✅ | ❌ | ✅ | ✅ | Can submit incidents and view or export closed ones in their area but cannot view others' open incidents. |
| 14 | ❌ | ✅ | ✅ | ✅ | Investigator-style access: can view or edit all assigned open and closed incidents. |
| 15 | ✅ | ✅ | ✅ | ✅ | Access to submit, view open, and view closed incidents they are allowed to see based on access settings. |
4. Working with system roles in the Incident Module
System access roles are set when creating a new user or editing an existing user's profile, managed under the ROLE field. By default, all users are assigned the General User role to limit access to only the information they need. Each role has different permissions, and within the Incident Module, these roles can perform the tasks listed below without any additional configuration.
General User
A General User is typically someone working in the field, lab, or office who needs a quick and easy way to report safety concerns. Their goal is to report issues quickly to help keep the workplace safe and prevent future problems.
What they can do:
- Submit incident reports (injuries, near-misses, property damage, spills, etc.)
- Attach photos or documents to support their report
- View the status of incidents they have submitted (if allowed)
Area Manager
Area Managers oversee specific departments, teams, or spaces and ensure incidents are followed up on correctly. Their goal is to ensure that all incidents are handled promptly and corrective actions are taken to reduce risk.
What they can do:
- Review and verify submitted incident reports
- Assign investigators or corrective actions
- Monitor trends within their area
- Communicate follow-up steps to their team
Note: Access Roles must also be configured to give area level oversight.
Inspector
Inspectors focus on safety compliance, audits, and investigating what caused an incident. Their goal is to understand what happened, why it happened, and help prevent it from happening again.
What they can do:
- Investigate assigned incidents
- Complete root cause analysis
- Recommend corrective or preventive actions
- Close out investigations once finished
Note: Access Roles must also be configured to give area level oversight.
Administrator
Administrators are typically safety leads or system owners who manage settings, permissions, and high-level reporting. Their goal is to keep the system running smoothly, align it with organizational needs, and provide safety leadership with the data they need.
What they can do:
- Configure the incident form and customise workflows
- Set role-based access and manage user permissions
- Create categories, alerts, and notification rules
- Run reports across teams, departments, or the entire organisation