> For the complete documentation index, see [llms.txt](https://kitehouse.co.uk/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kitehouse.co.uk/docs/admin/settings/roles.md). # Roles Roles allows you to customise the permission level given to your staff members. You can assign roles to your staff members using the Staff tab.

## Creating a Role To create a role, follow the steps below: {% stepper %} {% step %} ### Go to the Roles Tab You can do this by going to **Site Settings** then selecting the **Roles** section on the sidebar. {% endstep %} {% step %} ### Create a Role Click **Create Role** to create a new role. Click the newly-created role to expand it's options.\ \ Once expanded, you can change the name of the role, will they require email login and the permissions given to them. {% endstep %} {% endstepper %} ### Permission Details {% tabs %} {% tab title="Incident Tab" %} These are the permissions that you may give out to your staff members that creates incidents.

Name of Permission	Description
Incident View	Allows them to view the Incident Page.
Incident View Own	Allows them to only view the incidents assigned to them.
Incident Create	Allows them to create incidents.
Incident Edit	Allows them to edit incident details.
Incident Close	Allows them to close incidents.
Incident Delete*	Allows them to delete incidents.
Incident Assign	Allows them to assign incidents to staff members.
Incident View Sensitive	Allows them to view sensitive incidents.
Incident Export	Allows them to export incidents.
Comment Create	Allows them to create comments.
Comment Delete Own	Allows them to delete their own comments.
Comment Delete Any*	Allows them to delete any of the comments in an incident.
Attachment Upload	Allows them to upload attachments in an incident.
Attachment Download	Allows them to download the attachments linked to an incident.
Attachment Delete	Allows them to delete attachments linked to an incident.

**Please Note:** Permissions with an **asterisk (\*)** can be abusive. {% endtab %} {% tab title="Student Tab" %} These are the permissions that allows your staff members to have access to student data.

Name of Permission	Description
Student View	Gives them access to the Student tab.
Student Create	Allows them to create a student in Kitehouse.
Student Edit	Allows them to edit the information regarding a student.
Student Delete*	Allows them to delete students stored in Kitehouse.
Student Import	Allows them to import student data to Kitehouse.
Student Export	Allows them to export student data out of Kitehouse.

**Please Note:** Permissions with an **asterisk (\*)** can be abusive. {% endtab %} {% tab title="Other Permissions" %} These are other permissions that allows your staff to access different tabs in Kitehouse.

Name of Permission	Description
Dashboard View	Gives them access to the Dashboard tab.
Audit View	Gives them access audit history in an incident.
Staff Manage*	Allows them to add/remove staff members.
Settings Manage*	Allows them to manage Site settings.
Quality Gates Manage
Governance View	Gives them access to the Governance View
Governance Export	Allows them to export reports from the Governance View.

**Please Note:** Permissions with an **asterisk (\*)** can be abusive. {% endtab %} {% endtabs %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://kitehouse.co.uk/docs/admin/settings/roles.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.