Base Platform roles

16 min

Role name	Description
platform_selfservice	This is the base role provided to any self service user in the system. This role was introduced to allow commonly used table by self service to be tied to one role, as opposed to many. Within this role, the user won't be able to see or do anything in the system, including even seeing their own name.
platform_agent	This is the base role provided to any agents in the system. This role was introduced to allow commonly used table by agents to be tied to one role, as opposed to many. This means that tables such as groups are tied to this role, as opposed to each application separately.
platform_data_administrator	This is the highest privileged role in terms of managing the base data within the system.
configuration_admin	This is the highest privileged role for configuring the system, minus the ability to script.
application_administrator	The role required in conjunction with the application specific role to provide them administrative like privileges to platform tables for their tables (for example, classification)
administrator	This is the highest privilege role in the system. They can see and do anything in the platform (on the application layer) that is possible.

Summary of the security model

The security model was set up in a way that ensures that the platform is not necessarily focused on one business area. What this means is that service management platforms are commonly set up and focused on IT side of the business, by having roles or otherwise require some role related to the platform's ITSM suite. However in Servicely is was set up so there are base platform roles, which provide a base level of permissions and then any application on top of that (ITSM, HR or otherwise) requires their own role set to see the required tables. In addition to this, this, it was set up in a way that business units have permission to configure some of their own records (such as classification) with a combination of the application admin role and for example the ITSM administrator role. Once again, trying to lessen the amount of focus on the IT business area within the platform.

Finally, the platform data administrator and configuration admin roles was to try to separate some of the responsibilities that are often put onto the system administrator. The platform data administrator role provides the ability to update, delete and more platform data within the system, such as users or otherwise, which often administrators have to do. Whilst configuration admin allows the administration of some of the more day to day activities without scripting.

It should be noted that from a scripting perspective however, this is only ever users with the administrator role, to ensure that users cannot give themselves more privileges than they should have. To ensure this is locked down, there are permissions to ensure that users that only have platform data administrator and not administrator cannot update administrator users and so forth.

How various platform table's security works.

Classification

Permission type	Security model	Why was it set up like this?
Create classification	There are essentially two levels of security for creating classifications. Can always create a classification: Users that have the administrator role can create classifications for any tables.Can only create some classifications: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can create classifications in the tables in the itsm application (for example incident) or hr administrators can create classifications in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to create a classification for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to create the classifications they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Read classification	Anyone with the platform agent role can read any classification	Although we could potentially separate this by the table / application it is focused on, it does not really matter as classifications are not considered sensitive.
Update classification	There are essentially two levels of security for updating classifications. Can always update a classification: Users that have the administrator role can update classifications for any tables.Can only update some classifications: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can update classifications in the tables in the itsm application (for example incident) or hr administrators can update classifications in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to update a classification for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to update the classifications they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Delete classification	There are essentially two levels of security for deleting classifications. Can always delete a classification: Users that have the administrator role can delete classifications for any tables.Can only delete some classifications: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can delete classifications in the tables in the itsm application (for example incident) or hr administrators can delete classifications in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to delete a classification for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to delete the classifications they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.

Department

Permission type	Security model	Why was it set up like this?
Create department	Anyone with the platform data administrator or administrator role(s) can create a department.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Read department	Anyone with the platform agent role can read a department.	This was done as agents often need to read the department to do their job correctly.
Update department	Anyone with the platform data administrator or administrator role(s) can update a department.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Delete department	Anyone with the platform data administrator or administrator role(s) can delete a department.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.

Group

Permission type	Security model	Why was it set up like this?
Create group	Anyone with the platform data administrator or administrator role(s) can create a group.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Read group	Anyone with the platform agent role can read a group.	This was done as agents often need to read the department to do their job correctly. It does not matter if they can read groups part of other processes, as this is not considered sensitive data.
Update group	Anyone with the platform data administrator or administrator role(s) can update a group, except for the roles associated to a group that only administrators can update.	This was done to ensure that the system administrator does not need to also maintain all the data within the system and that platform data administrators can not give themselves administrator through a group by updating the roles associated to a group and associating that role to themselves.
Delete group	Anyone with the platform data administrator or administrator role(s) can delete a group.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.

Role

Permission type	Security model	Why was it set up like this?
Create role	Only administrators can create new roles.	As roles are often tied to permissions, which are a very admin focused function, it was decided that only administrators can do this.
Read role	Anyone with the platform agent role can read a role.	This was done as often the role associated to a record helps a user understand the impact of having things there. An example of this are the roles for visibility for knowledge bases.
Update role	Only administrators can update roles.	As roles are often tied to permissions, which are a very admin focused function, it was decided that only administrators can do this.
Delete role	Only administrators can delete roles.	As roles are often tied to permissions, which are a very admin focused function, it was decided that only administrators can do this.

Company

Permission type	Security model	Why was it set up like this?
Create company	Anyone with the platform data administrator or administrator role(s) can create a company.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Read company	Anyone with the platform self service role can read a company. Except for the contact details where a user needs the platform_agent role.	This was set up this way, as in MSP situations, self service users often need to pick a company. In addition to this, company data is not considered sensitive (other than the contact details, hence why that was locked down), so it is not a big deal. For example, contacting a third party directly as a platform self service user.
Update company	Anyone with the platform data administrator or administrator role(s) can update a company.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Delete company	Anyone with the platform data administrator or administrator role(s) can delete a company.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.

Country

Permission type	Security model	Why was it set up like this?
Create country	Anyone with the platform data administrator or administrator role(s) can create a country.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Read country	Anyone with the platform self service role can read a country.	This was set up this way as countries are not really considered sensitive detail and may help in situations where self service users need to pick a location from the country they are in.
Update country	Anyone with the platform data administrator or administrator role(s) can update a country.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Delete country	Anyone with the platform data administrator or administrator role(s) can delete a country.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.

State Province

Permission type	Security model	Why was it set up like this?
Create state province	Anyone with the platform data administrator or administrator role(s) can create a state province.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Read state province	Anyone with the platform self service role can read a state province.	This was set up this way as states or provinces are not really considered sensitive detail and may help in situations where self service users need to pick a location from the state or province they are in.
Update state province	Anyone with the platform data administrator or administrator role(s) can update a state province.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Delete state province	Anyone with the platform data administrator or administrator role(s) can delete a state province.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.

Location

Permission type	Security model	Why was it set up like this?
Create location	Anyone with the platform data administrator or administrator role(s) can create a location.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Read location	Anyone with the platform self service role can read a location.	This was set up this way as locations are not really considered sensitive detail and may help in situations where self service users need to pick a location for where an issue, request or case is for.
Update location	Anyone with the platform data administrator or administrator role(s) can update a location.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Delete location	Anyone with the platform data administrator or administrator role(s) can delete a location.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.

User

Permission type	Security model	Why was it set up like this?
Create user	Anyone with the platform data administrator or administrator role(s) can create a user.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Delete user	Anyone with the platform data administrator or administrator role(s) can delete a user.	This was done to ensure that the system administrator does not need to also maintain all the data within the system.
Read user	Anyone with the self service role can read any user in the system.	This was set up this way, as often users need to pick out another user for who the issue, case or request is for. This may need to be locked down in the future, but made sense as an initial step, as in smaller organisations the sort of data that is held on the user record at the moment, is the sort of information that is available in other areas of the business anyway.
Update user	Anyone with the platform data administrator or administrator role(s) can update a user. However, platform data administrators can only update the following fields for users that are not administrators. Password Failed login attempts Locked out In addition to this, platform data administrators can never update a users roles, no matter what the role.	This was done to ensure that the system administrator does not need to also maintain all the data within the system. However it was important that platform data administrators were not given the ability to update administrators and potentially lock them out / change their passwords or roles.

SLA Definitions

Permission type	Security model	Why was it set up like this?
Create SLA definition	There are essentially two levels of security for creating SLA definitions. Can always create a SLA definition: Users that have the administrator role can create SLA definitions for any tables. Can only create some SLA definitions: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can create SLA definitions in the tables in the itsm application (for example incident) or hr administrators can create SLA definition in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to create a SLA definition for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to create the SLA definitions they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Delete SLA definition	There are essentially two levels of security for deleting SLA definitions. Can always delete a SLA definition: Users that have the administrator role can delete SLA definitions for any tables. Can only delete some SLA definitions: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can delete SLA definitions in the tables in the itsm application (for example incident) or hr administrators can delete SLA definition in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to delete a SLA definition for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to delete the SLA definitions they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Read SLA definition	There are essentially two levels of security for creating SLA definitions. Can always read a SLA definition: Users that have the administrator role can read SLA definitions for any tables. Can only read some SLA definitions: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can read SLA definitions in the tables in the itsm application (for example incident) or hr administrators can read SLA definition in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to read a SLA definition for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to read the SLA definitions they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Update SLA definition	There are essentially two levels of security for updating SLA definitions. Can always update a SLA definition: Users that have the administrator role can update SLA definitions for any tables. Can only update some SLA definitions: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can update SLA definitions in the tables in the itsm application (for example incident) or hr administrators can update SLA definition in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to update a SLA definition for that table. In addition to this, this second level of security will never allow users to update the following fields: Cancel condition script Stop condition script Pause condition script Start condition script	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to update the SLA definitions they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of. The scripting fields have been locked down to prevent non administrators from scripting or doing anything via the script they should not be able to.

Outbound notifications

Permission type	Security model	Why was it set up like this?
Create outbound notification	There are essentially two levels of security for creating outbound notifications. Can always create an outbound notification: Users that have the administrator role can create outbound notifications for any tables. Can only create some outbound notifications: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can create outbound notifications in the tables in the itsm application (for example incident) or hr administrators can create outbound notifications in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to create an outbound notification for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to create the outbound notifications they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Read outbound notification	There are essentially two levels of security for reading outbound notifications. Can always read an outbound notification: Users that have the administrator role can read outbound notifications for any tables. Can only read some outbound notifications: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can read outbound notifications in the tables in the itsm application (for example incident) or hr administrators can read outbound notifications in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to read an outbound notification for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to read the outbound notifications they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Update outbound notification	There are essentially two levels of security for updating outbound notifications. Can always update an outbound notification: Users that have the administrator role can update outbound notifications for any tables. Can only update some outbound notifications: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can update outbound notifications in the tables in the itsm application (for example incident) or hr administrators can update outbound notifications in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to update an outbound notification for that table. However, a user needs the system administrator role to update the following fields on the outbound notification: Recipients Condition Body Subject	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to update the outbound notifications they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of. However, certain fields were locked down, as these are simply scripts that configuration administrators should not be able to write for security reasons.
Delete outbound notification	There are essentially two levels of security for deleting outbound notifications. Can always delete an outbound notification: Users that have the administrator role can delete outbound notifications for any tables. Can only delete some outbound notifications: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can delete outbound notifications in the tables in the itsm application (for example incident) or hr administrators can delete outbound notifications in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to delete an outbound notification for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to delete the outbound notifications they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.

Reclassification field map

Permission type	Security model	Why was it set up like this?
Create reclassification field map	There are essentially two levels of security for creating reclassification field maps. Can always create a reclassification field map: Users that have the administrator role can create reclassification field maps for any tables.Can only create some reclassification field maps: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can create reclassification field maps in the tables in the itsm application (for example incident) or hr administrators can create reclassification field maps in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to create a reclassification field maps for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to create the reclassification field maps they need to, without bothering the system administrator. By doing create, it allows business units to be in control of the data they need to be in control of.
Read reclassification field map	There are essentially two levels of security for creating reclassification field maps. Can always read a reclassification field map: Users that have the administrator role can read reclassification field maps for any tables.Can only read some reclassification field maps: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can read reclassification field maps in the tables in the itsm application (for example incident) or hr administrators can read reclassification field maps in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to read a reclassification field maps for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to read the reclassification field maps they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.
Update reclassification field map	There are essentially two levels of security for creating reclassification field maps. Can always update a reclassification field map: Users that have the administrator role can update reclassification field maps for any tables.Can only update some reclassification field maps: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can update reclassification field maps in the tables in the itsm application (for example incident) or hr administrators can update reclassification field maps in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to update a reclassification field maps for that table.However, a user needs the system administrator role to update the following fields on the reclassification field map:- Script	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to update the reclassification field maps they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of. However, certain fields were locked down, as these are simply scripts that configuration administrators should not be able to write for security reasons.
Delete reclassification field map	There are essentially two levels of security for creating reclassification field maps. Can always delete a reclassification field map: Users that have the administrator role can delete reclassification field maps for any tables.Can only delete some reclassification field maps: Users that have the application admin role and the role outlined in the table's application's associated application property <application_name>.application_admin.role_required" role. For example, itsm administrators can delete reclassification field maps in the tables in the itsm application (for example incident) or hr administrators can delete reclassification field maps in the tables in the hr application (for example hr case). In situations where that application does not have the property, a user just needs the configuration admin role to delete a reclassification field maps for that table.	It was set up this way to ensure that administrators of business units of the tables they use mostly are able to delete the reclassification field maps they need to, without bothering the system administrator. By doing this, it allows business units to be in control of the data they need to be in control of.

Application properties

Permission type	Security model	Why was it set up like this?
Create application property	Only system administrators can create application properties.	As application properties are often created to be used in scripts, allowing other types of users who cannot update scripts to create them is pointless.
Read application property	Only the role(s) outlined within the roles field on an application property can read the associated application property. If the field is blank, only administrators can read it.	This was done to allow the segregated administration model, to allow other roles to read application properties, when they need to.
Update application property	Only the role(s) outlined within the roles field on an application property can update the associated application property. If the field is blank, only administrators can update it. In addition to this, the following fields can only be updated by a system administrator (therefore only allowing the description and application property value to be changed by the role: Roles Application property key Property type Organization	This was done to allow the segregated administration model, to allow other roles to update application properties, when they need to. The other fields were locked down, due to the fact that changing the other fields that have been locked down could have a potential negative impact to the system.
Delete application property	Only system administrators can delete application properties.	Due to the potential impact of deleting an application property, this has been locked down to ensure that the impact is not taken lightly.