overview please be aware that read only users may have licensing implications, please talk to your account manager if you are unsure we also strongly testing this on your non production(s) prior to applying it to any users in production when possible to allow our users to have much more control and a read only view of the itsm platform, we have introduced a new itsm read only role to the system this role provides the read capabilities of an agent, where the whole form (minus the client journal for incident/request) will always be read only this is only relevant for users who are not agents of the platform this article describes its capabilities and any considerations to make if you are an existing user and want to add this how to utilise to utilise the itsm read only role, there are a few steps to make full use of it the below describes what these steps are, and more details can be found in the capabilities and functionality section if you are not sure if you are entitled to use this role, please confirm with your account manager regarding your license entitlements create the appropriate menu items/sections/applications and / or update existing menu items to give them access to certain menu items give the appropriate users the role of itsm read only (either group inheriting from a group or otherwise) please note, we would suggest to avoid giving this to itsm agents, as the itsm agents give all capabilities this role already provides and may conflict if you would like to give them report creation capabilities, provide the appropriate users the role of report creator (either group inheriting from a group or otherwise) please note that we have the platform read only role inherit this out the box if you would like to give them cmdb viewing capabilities, provide the appropriate users the role of cmdb viewer (either group inheriting from a group or otherwise) review your sla definitions and determine if they should be able to see future slas created against the definitions run the appropriate migration script (if desired) to update pre existing slas with the new role capabilities and functionality to allow users to get read only access to the out of box itsm related tables, you are able to give users the itsm read only role, which by default also provides them the platform read only table these roles are expected to be mutually exclusive to itsm agent role, in a sense it is only expected a user has one role or the other it is also expected that these users already have the platform selfservice role the itsm read only table will provide read access to the following itsm tables itsm work incident incident task itsm request itsm request task problem problem task change change task however, to support this, it also gives read capabilities to other data tables to allow them to see the appropriate information (slas, classifications, groups, departments and more) from an update perspective however, users will still be able to raise their own incidents/requests, but also be able to update the client journal for all incidents/requests it does not provide the ability to update the work journal or any other fields for records that they are not the requestor / requested for incident / requests and no capability to update any other fields for the other record types if a user needs the ability to update the other fields that do not fall into the above category, they are considered an agent in addition to this, outside of being able to cancel/resolve incidents/requests, they cannot change the workflow status and cannot create knowledge articles reporting itsm read only users are also able to create their own (private) dashboard and reports they are not allowed to make reports / dashboards for other people, but are able to look at any non private dashboards and reports that have been shared to them the way this can be done is with also providing itsm read only users the report creator role noting that the report editor role is for agents and above for details in how to create reports and dashboards, please see reports and dashboards docid\ tx7p2n o cgvl85yzieda cmdb out the box there is already a read only role for the cmdb called cmdb viewer as a result, you are able to provide read only users this cmdb viewer role to give them read only capability to the cmdb and cmdb fields noting that if you provide users the cmdb manager role, they will be considered agents menu access out the box we have made the decision not to include any menu items specifically for the itsm read only user if you wish to do so, and have your itsm read only user see the left menu, you can provide the navigation menu role and also ensures you create menu items specifically for them please note however, admins will always see these menu items, but otherwise you can make menu items only visible to people with the appropriate roles (hence our recommendation to use itsm read only mutually exclusive to itsm agents) please see navigation menu docid\ pqzy31 4s6mcartknfkos for more details existing customer considerations this is only relevant for existing servicely customers who have updated their default security rules or have introduced other itsm agent only fields to their itsm agent flows as a result, this page details if something does not appear quite right, what the cause / reason may be and steps to potentially resolve it records are not showing if the records are not showing that you are expect, it is likely due to an edit that was made to your table record restriction or you already have one existing that you would need to edit out the box there were 2 record restrictions that were updated, which are for incident and request previously the table record restriction hid any record if you are not an agent to only ones where you are the requestor, requested for or approver (for itsm request), however, to support the itsm read only role, this (for incident ) for example has gone from if (!user hasrole("itsm agent") { answer = or( equal("requestor", user getid()), equal("requestedfor", user getid()) ); } to if (!user hasanyrole("itsm agent","itsm read only")) { answer = or( equal("requestor", user getid()), equal("requestedfor", user getid()) ); } essentially saying if a user has itsm agent or itsm read only, they are not restricted to be seen if you have updated your table record restriction, it is likely there are other considerations to make to updating your rule however, the above example should illustrate what change was made to support this and what sort of change you would need to change to support this fields are not showing out the box for itsm work, incident and itsm request, there are field level permissions to deny access to certain fields, as per below (using the example of itsm work) please note, this may differ depending on your configuration or extra requirements you may have as part of the itsm read only role implementation, we have also introduced additional field level permissions for itsm work, incident and itsm request, which work in tandem with pre existing permissions the below example is a standard deny permission with order 10, that only lets itsm agents read those fields to allow itsm read only users to read those fields, we introduced an earlier order allow permission for the same fields in doing so, this overrules the other permission, providing users access to these fields that said, if you have a number of new fields or another similar permission, the new permission we created will not include your new fields as a result, you would need to manually add those fields to the permission above (for incident, itsm request or itsm work) to give them access to those fields it should also be noted that in some occasions certain fields may also not show as the user does not have visibility to the underlying table the read only role can be added to read other data tables if required from a permission perspective cannot read any existing slas as part of your setup, it is likely you have set up new slas as part of the out of box experience, we have added the new itsm read only role to the out of box sla definitions this will mean any slas created after the date the release that includes this functionality was applied to your environment, will be visible to users, if you are using the out of box sla definitions the roles field for sla definitions essentially mean that users who have one of those roles listed, will be able to read the sla records that are generated this role is added when the sla is generated, so will only apply after this role is added to the sla definition if you do not wish the itsm read only user to be able to read the slas, you can remove that role from the sla definition roles field however, if you want to allow them to see any sla before this patch has been applied, you will need to consider updating the roles field in the sla records, to the desired value(s)