Base Platform roles

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