HR Permissions & Roles
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:
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:
| 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:
| 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