hr specific roles role name description hr agent this is the base role provided to any agents in the system for the hr application any specific functionality to any specific hr tables should be created separately hr manager this role provides an expanded set of privileges for the hr application and associated tables hr administrator this is the highest privileged role for the hr application and associated tables and provides the ability to edit properties and delete records how hr application security works the itsm application in sevricely 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 hr work note that hr 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 hr work only an administrator or hr 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 hr case, hr case task, etc read hr work any user who has the hr agent role can read records here as this table will often be used for queue management or reporting update hr work only an administrator or hr 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 hr case, hr case task, etc delete hr work only an administrator or hr 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 hr case, hr case task, etc hr case permission type security model why was it set up like this? create a hr case any user with the self service role can create a hr case as this is the process where users raise hr cases, self service users are able to create these directly if they know it is the correct place read a hr case for hr cases, there are essentially three levels of security can read any hr case users who have the hr administrator or administrator role have the ability to read any hr case in the system can read all non restricted hr cases these are users who have the hr agent role and have the ability to read the majority of the hr cases in the system for the user to be able to read the hr case, one of the following conditions must occur they are the requested for they are the requestor they are an approver they are a collaborator they are a follower if a group or multiple groups have been entered into the restricted visibility group, a hr agent will need to be part of at least one of the groups listed to be able to see the record if a user or multiple user have been entered into the restricted visibility user and their user is listed the restricted visibility group and the restricted visibility user fields are both empty basic hr case visibility the basic level of visibility for hr cases is where as users don't have the hr 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 assignment group assignee classification completion notes restricted visibility group restricted visibility user service subtasks collaborator 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 in addition to this the mid level visibility was put in place for potentially sensitive hr cases, where only select groups or people should be able to view and edit a hr case update a hr case any user with the self service role can edit a hr case, assuming they can read it or field to begin with if a user can read the field or record, they can update the hr case therefore see the read section for the details around this delete a hr case only users who have the hr 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 hr case task permission type security model why was it set up like this? create a hr case task any user with the hr agent role can create a hr case task as this is a very hr 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 hr case task there are two different levels of visibility for hr case tasks can always read a hr case task users that have the administrator or hr administrator role(s) can read an hr request task no matter what can read all non restricted hr case tasks these are users who have the hr agent role and have the ability to read the majority of the hr case tasks in the system for the user to be able to read the hr case tasks, one of the following conditions must occur if a group or multiple groups have been entered into the restricted visibility group, a hr agent will need to be part of at least one of the groups listed to be able to see the record if a user or multiple user have been entered into the restricted visibility user and their user is listed the restricted visibility group and the restricted visibility user fields are both empty they are a collaborator as this is a very hr centric function that is not centred around involving a client directly, this has been locked down to ensure only agents can read these records in addition to this, sensitive / restricted information may be found only in the task, so these have their own seperate restrictions if required update a hr case task there are essentially two levels of security for hr case tasks (assuming they can read it to begin with) can always update a hr case task users that have the administrator or hr administrator role(s) can update an hr request task no matter the status can only update open hr case tasks users that have the hr agent role can only update an ithrsm 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 a hr case task only users who have the hr 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 hr processes, there are essentially four main "personas" that align with this process therefore this section details the four 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 hr manager description this is the user who is in charge of the whole hr 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 hr department, they are often the ones who need to review knowledge articles, change classifications and are allowed to see any case in the system roles recommended knowledge manager knowledge editor hr administrator hr manager hr agent application administrator 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 hr restricted access users description these are the hr users that often have security over and above of the normal hr user they are also often the ones that need specific access to specific hr cases roles recommended knowledge editor platform selfservice platform agent hr manager hr agent hr case worker description these are the individuals who work day in and day out on hr related matters roles recommended knowledge editor platform agent platform selfservice hr agent any other user in the organisation description these are the users who are not a part of the hr team they are a part of the organisation, but need to be able to raise hr cases, as well as view their own hr cases roles recommended platform selfservice