Roles and permissions
Two separate labels control how you appear and what you can do. Your Organisation Type describes who you work for. Your Role describes what you are allowed to change. Both are set by an administrator.
Organisation types
| Organisation type | Typically | Usual role |
|---|---|---|
| Council | The road controlling authority or client organisation. | Commenter |
| Consultant | Engineering or professional services advising on the work. | Editor |
| Contractor | The party carrying out physical work on site. | Editor |
| Other | Anyone who does not fit the above, for example an auditor or a third-party stakeholder. | View only |
Organisation type does not by itself grant or remove permissions — your role does. It provides context: when you read a note on a timeline it matters whether it came from the contractor or from the council.
The "usual role" column is the convention on this programme, and it is what the invitation form suggests when an administrator chooses an organisation type. The council comments on the record; the consultants and contractors doing the work also maintain it. An administrator can assign a different role where a particular person needs one.
The five roles
Super Admin. Full access across the deployment, including organisations, projects, users and all issue data. Super Admins are the only people who can see everything. There is one Super Admin on this programme, and it is not tied to any council, consultancy or contractor.
Admin. Manages users within their scope: sends invites, sets roles and organisation types, and has full access to issues.
Editor. The working field and office role. Editors create issues, upload photos, edit issue details, change statuses and add timeline notes.
Commenter. Can read everything they have access to and add notes to issue timelines, but cannot create issues or change issue fields.
View only. Read-only. Can see the map, the issue list, issue details and timelines, and can add nothing.
What each role can do
| Action | Super Admin | Admin | Editor | Commenter | View only |
|---|---|---|---|---|---|
| View the map, issues and timelines | Yes | Yes | Yes | Yes | Yes |
| Add a note to a timeline | Yes | Yes | Yes | Yes | No |
| Upload a photo and create an issue | Yes | Yes | Yes | No | No |
| Edit issue name, address, type, description, recorded date | Yes | Yes | Yes | No | No |
| Change an issue status | Yes | Yes | Yes | No | No |
| Invite users and send invite links | Yes | Yes | No | No | No |
| Assign roles and organisation types | Yes | Yes | No | No | No |
| See across all organisations | Yes | No | No | No | No |
If you are a Commenter and you need to correct a factual error in an issue — a wrong address, the wrong issue type — add a note saying so and ask an Editor to make the change. The note becomes part of the record, which is usually better than a silent edit anyway.
Why roles are kept tight
The issue register is used to agree what was found, when, and what was done about it. Restricting who can change stored facts, while letting a wide group add to the timeline, keeps the record trustworthy without slowing down communication. Every change that is made is also written to the audit trail — see Administration.