ITSM permission and roles
- Michael Luecke (Unlicensed)
- Servicely AI Smart, Simple, Better Service Desk (Unlicensed)
ITSM specific roles
| Role name | Description |
|---|---|
| itsm_agent | This is the base role provided to any agents in the system for the ITSM application. Any specific functionality to any specific ITSM tables should be created separately. |
| itsm_manager | This role provides an expanded set of privileges for the ITSM application and associated tables. |
| itsm_administrator | This is the highest privileged role for the ITSM application and associated tables and provides the ability to edit properties and delete records. |
How ITSM application security works
The ITSM application in Servicely covers a range of different tables and processes and as a result of this, the number of permissions and complexity differs for each of the processes. Some processes are focused on helping self service users, whilst others are very specific tasks and the permissions reflect as much.
ITSM Work
Note that ITSM Work is more of a table used for reporting, as opposed to process. Therefore its child tables will normally do the restricted, as opposed to the table itself
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create ITSM work | Only an administrator or ITSM administrator can create these records. | In reality no one should be creating these records and should only be creating records in the child tables, such as incident, problem, change, etc. |
| Read ITSM work | Any user who has the ITSM agent role can read records here. | As this table will often be used for queue management or reporting. |
| Update ITSM work | Only an administrator or ITSM administrator can update these records. | In reality no one should be updating these records and should only be updating records in the child tables, such as incident, problem, change, etc. |
| Delete ITSM work | Only an administrator or ITSM administrator can delete these records. | In reality no one should be deleting these records and should only be deleting records in the child tables, such as incident, problem, change, etc. |
Incident
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create an incident | Any user with the self service role can create an incident. | As this is the process where users raise IT issues, self service users are able to create these directly if they know it is the correct place. |
| Read an incident | For incidents, there are essentially two levels of security. Can read any incident: Users that have the ITSM agent role can read an incident in the system, as well as any field on the incident form. Basic incident visibility: The basic level of visibility for incident is where as users don't have the ITSM agent role, but do have the platform self service role. These users are only able to see records where they are the requested for or requestor. In addition to this, users with only this role can never read information in the following fields:
| The cut down security is to ensure that only people who are working on them can see all records, whilst if someone is requesting something for someone else or themselves, it makes sense they are able to see the record, or else they won't have the context behind it. The basic level of visibility however was set up with the intention that records that a user should be able to see, they are able to see, whilst restricting fields that serve no real purpose for the self service user or will provide details that should not be provided to prevent them contacting agents directly or where sensitive data may be held. |
| Update an incident | Any user with the self service role can edit an incident, assuming they can read it or field to begin with. | If a user can read the field or record, they can update the incident. Therefore see the read section for the details around this. |
| Delete an incident | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
Incident task
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create an incident task | Any user with the ITSM agent role can create an incident task. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can create these records. |
| Read an incident task | Any user with the ITSM agent role can read any incident task. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can read these records. |
| Update an incident task | There are essentially two levels of security for incident tasks. Can always update an incident task: Users that have the administrator or ITSM administrator role(s) can update an incident task no matter the status. Can only update open incident tasks: Users that have the ITSM agent role can only update an incident task when the status is not closed or cancelled. | As tasks are centred around completing bits of work to complete its parents, the client associated with the actual parent should not need to see anything here. It is locked down when it is closed, to ensure data integrity and so people complete the work when the task is open, as opposed to retroactively. |
| Delete an incident task | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
ITSM Request
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create an ITSM Request | Any user with the self service role can create an ITSM request. | As this is the process where users raise IT issues, self service users are able to create these directly if they know it is the correct place. |
| Read an ITSM Request | For ITSM requests, there are essentially two levels of security. Can read any ITSM request: Users that have the ITSM agent role can read an ITSM request in the system, as well as any field on the ITSM request form. Basic incident visibility: The basic level of visibility for ITSM requests is where as users don't have the ITSM agent role, but do have the platform self service role. These users are only able to see records where they are the requested for, requestor, or an approver. In addition to this, users with only this role can never read information in the following fields:
| The cut down security is to ensure that only people who are working on them can see all records, whilst if someone is requesting something for someone else or themselves, it makes sense they are able to see the record, or else they won't have the context behind it. The basic level of visibility however was set up with the intention that records that a user should be able to see, they are able to see, whilst restricting fields that serve no real purpose for the self service user or will provide details that should not be provided to prevent them contacting agents directly or where sensitive data may be held. |
| Update an ITSM Request | Any user with the self service role can edit an ITSM request, assuming they can read it or field to begin with. | If a user can read the field or record, they can update the ITSM request. Therefore see the read section for the details around this. |
| Delete an ITSM Request | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
ITSM Request task
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create an ITSM Request task | Any user with the ITSM agent role can create an ITSM request task. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can create these records. |
| Read an ITSM Request task | Any user with the ITSM agent role can read any ITSM request task | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can read these records. |
| Update an ITSM Request task | There are essentially two levels of security for ITSM request tasks. Can always update an ITSM request task: Users that have the administrator or ITSM administrator role(s) can update an ITSM request task no matter the status. Can only update open ITSM request tasks: Users that have the ITSM agent role can only update an ITSM request task when the status is not closed or cancelled. | As tasks are centred around completing bits of work to complete its parents, the client associated with the actual parent should not need to see anything here. It is locked down when it is closed, to ensure data integrity and so people complete the work when the task is open, as opposed to retroactively. |
| Delete an ITSM Request task | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
Change
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create a change | Any user with the ITSM agent role can create a change. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can create these records. |
| Read a change | Any user with the ITSM agent role can read any change. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can read these records. |
| Update a change | There are essentially two levels of security for changes Can always update a change: Users that have the administrator or ITSM administrator role(s) can update a change no matter the status. Can only update open changes: Users that have the ITSM agent role can only update a change when the status is not closed. In addition to this, they can only update the change type, when its status is new or in peer review. | As per the read permission, but the type field has been locked down to ensure users don't try to get around approval processes, once it has been reviewed. |
| Delete a change | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
Change task
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create a change task | Any user with the ITSM agent role can create a change task. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can create these records. |
| Read a change task | Any user with the ITSM agent role can read any change task. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can read these records. |
| Update a change task | There are essentially two levels of security for change tasks Can always update a change task: Users that have the administrator or ITSM administrator role(s) can update a change task no matter the status. Can only update open change tasks: Users that have the ITSM agent role can only update a change task when the status is not closed or cancelled. | As per the read permission, but locked down when closed to ensure data integrity and to ensure work is captured correctly and work is not done retroactively when it can be avoided. |
| Delete a change task | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
Problem
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create a problem | Any user with the ITSM agent role can create a problem. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can create these records. |
| Read a problem | Any user with the ITSM agent role can read any problem. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can read these records. |
| Update a problem | There are essentially two levels of security for problems. Can always update a problem Users that have the administrator or ITSM administrator role(s) can update a problem no matter the status. Can only update open problems: Users that have the ITSM agent role can only update a problem when the status is not closed. | As per the read permission, but locked down when closed to ensure data integrity and to ensure work is captured correctly and work is not done retroactively when it can be avoided. |
| Delete a problem | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
Problem task
| Permission type | Security model | Why was it set up like this? |
|---|---|---|
| Create a problem task | Any user with the ITSM agent role can create a problem task. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can create these records. |
| Read a problem task | Any user with the ITSM agent role can read any problem task. | As this is a very IT centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can read these records. |
| Update a problem task | There are essentially two levels of security for problem tasks. Can always update a problem task: Users that have the administrator or ITSM administrator role(s) can update an problem task no matter the status. Can only update open problem tasks: Users that have the ITSM agent role can only update a problem task when the status is not closed or cancelled. | As per the read permission, but locked down when closed to ensure data integrity and to ensure work is captured correctly and work is not done retroactively when it can be avoided. |
| Delete a problem task | Only users who have the ITSM administrator role or administrators can do this. | As it is recommended you do not delete these records due to audit and data integrity reasons, this has been locked down accordingly to only allow users who have higher privileges to be able to delete them. |
Recommended role allocation
Before allocating roles, remember to see what roles already include what roles automatically, as to not double up
When managing the various ITSM processes, there are essentially five main "personas" that align with this process. Therefore this section details the five main personas and what makes sense for their role allocation. Naturally, this is the lowest level of security for each and can be changed, but these are what we recommend.
IT Service Manager
Description: This is the user who is in charge of the whole IT department. In the long run it is up to them what classifications and processes are followed within the organisation and have the last say. However, due to the size of their IT department, they are often the ones who need to review knowledge articles, make changes directly into the CMDB and change classifications.
Roles recommended:
- knowledge_manager
- knowledge_editor
- itsm_administrator
- itsm_manager
- itsm_agent
- application_administrator
- cmdb_administrator
- cmdb_manager
- cmdb_viewer
- platform_selfservice
- platform_agent
Note: It is recommended they are also made the approver and manager of the knowledge base to ensure articles are approved when required and so they have special capabilities to expedite the workflow for the IT specific knowledge bases.
Service desk team leader
Description: The service desk team lead is the one in the organisation who manages the various employees in their service desk team. Although they often need to get involved in day to day activities, they often need to complete reporting for their manager.
Roles recommended:
- knowledge_editor
- platform_selfservice
- platform_agent
- itsm_manager
- itsm_agent
- cmdb_manager
- cmdb_viewer
IT service desk agent (Level 2/3 support)
Description: These are the individuals who work within the IT department and often complete the changes, investigate problems, as well as help in other more complex tasks. In addition to this, they often have to create knowledge articles to ensure that known errors, work arounds and major incidents are known about and information is made available.
Roles recommended:
- knowledge_editor
- platform_agent
- platform_selfservice
- cmdb_manager
- cmdb_viewer
- itsm_agent
Level 1 support agent
Description: These users are the ones who often triage cases and are the first point of contact for any IT issues within the organisation. However they never complete changes themselves and often only need to view configuration items, as opposed to edit them, as well as only view knowledge articles, as opposed to create them.
Roles recommended
- platform_selfservice
- platform_agent
- itsm_agent
- cmdb_viewer
Any other user in the organisation
Description: These are the users who are not a part of any service desk and don't complete any work within the IT department. They are a part of the organisation, but need to be able to raise IT issues, as well as view IT issues.
Roles recommended
- platform_selfservice
Related content
Servicely Documentation