within servicely the way to restrict certain information is largely done through referencing a user's set of roles or lack there of roles provide the ability to allow, restrict and logically separate visibility and access of records to users this is tied heavily with the security of records within the system and should be used as an additive approach in other words, if you want to provide access to a record, you would provide them with a role as opposed to checking if they don't have the role you can determine what roles a user has via server and client scripting, however certain functionality within the platform already accommodate a user's role composition, such as; permissions, menu items, application properties, table record restrictions, workflow transitions and more provided roles name application description cmdb administrator cmdb this is the highest privileged role for the cmdb application and associated tables and provides the ability to edit properties and delete records cmdb manager cmdb this role provides an expanded set of privileges for the cmdb application and associated tables cmdb viewer cmdb this is the base role for the cmdb table this only provides the ability to read the cmdb and a base level amount of information hr administrator hr this is the highest privileged role for the hr application and associated tables and provides the ability to edit properties and delete records hr manager hr this role provides an expanded set of privileges for the hr application and associated tables hr agent hr 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 itsm administrator itsm this is the highest privileged role for the itsm application and associated tables and provides the ability to edit properties and delete records itsm manager itsm this role provides an expanded set of privileges for the itsm application and associated tables itsm agent itsm 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 sofi administrator sofi this is the role given to users who can update the various elements of sofi it does not however give access to the script library or ui events, unless they have the other associated roles platform selfservice platform this is the base role provided to any internal 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 platform agent platform 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 platform data administrator platform this is the highest privileged role in terms of managing the base data within the system configuration administrator platform this is the highest privileged role for configuration, minus the ability to script application administrator platform 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) knowledge administrator knowledge this is the highest privileged role for the knowledge application and provides the ability to edit properties knowledge manager knowledge this role provides an expanded set of privileges for the knowledge application these users can skip workflow states and create/modify knowledge bases knowledge editor knowledge this is the base role for the knowledge application this essentially provides users the ability to create and update knowledge articles administrator platform role for administrators only users who have this role in the base system will have access to scripting capabilities recommended practice when developing a new application, it is recommended that you introduce a few different levels of permissions in doing so, it means that it's not a case of providing all or nothing access, but instead a more segmented approach to ensure that work can be done by more than just administrators the common recommended 3 level approach is as follows (note that is just recommended and your role structure can be as basic or as complex as you need) agent level provides basic process usage of the application such as a service desk user who needs to complete incidents, cases or otherwise they have no capabilities to delete records and may not have advanced functionality that may only occur through an escalation or otherwise manager level provides more advance functionality that needs to used sparingly or requires a certain level of responsibility associated to it this may include the ability to make an incident a major incident or shortcut approval processes administrator level provides administrative capability for that record that allows users who can delete the records or configure functionality connected to it this may include the ability to create classifications or change if a certain record requires approval or not in situations where as you are creating an application for users outside of your organisation, such as vendors, who should not have common self service visibility (such as being able to see other users in the system), it is recommended you do not alter the platform selfservice role to accommodate this, but instead make a different role for this purpose this way you can easily control and only add visibility to records that they should be able to read the platform selfservice role is meant to be the role provided to the majority of users to allow them to raise or read their own tickets (and the information they require to enter as such), but in records that may be for users outside of your organisation, you would often need to restrict the visibility of records even more application admin application administration is an optional extra that can be enabled for a table to provide a more segmented approach to administer certain functionality for an application, within needing to get a system administrator involved role inheritance when you are editing a role, it is possible to have a role contain other roles what this will do is that every time a user or group is provided the role that contains that role (and any roles that those contain), they will inherit any roles that are included there it is common practice that when you create an administrator role for an application, that the role that was created will contain any other role that was created for that application