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 major incident major incident review major incident journal major incident manager major incident followers sla status work journal priority assignment group assignee classification impact urgency resolution notes collaborator service related cofiguration items related incidents changes required related problems related sla's subtasks 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 sla status work journal priority assignment group assignee classification completion notes collaborator subtasks related configuration items service related sla's changes required 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