- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-30-2016 06:19 AM
Hi,
I have a requirement where, I need to grant access to ITIL user where the user can add new Category and add list of values to Sub-Categories. I checked the documentation and it says only Servicenow Admin role can perform it. Can you please help me to see if there is any alternate way to grant the permission to the user.
Solved! Go to Solution.
- Labels:
-
Incident Management

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-30-2016 06:50 AM
Hi Girish,
In general this is not a good practice. Categories & Subcategories for Incident are something that may change gradually over time, but should not be changing frequently enough that ITIL users need to update them. Additionally, ITIL users will rarely have a solid grasp of best practices when working with choices, which will most likely result in less than desirable options being added. Finally, the choices for Category and Subcategory live in the Choice[sys_choice] table, along with all other choices. As such you would have to write very specific ACLs to grant access to only these records, in addition to creating a module for users access the table to add/update records.
As an alternative to giving ITIL users direct access, I would recommend building a spreadsheet that they can populate with the new categories and subcategories that they provide to your admin team that then imports that spreadsheet. This will allow admin's to review the document prior to loading the new choices and ensure that best practices are being adhered to.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-30-2016 06:28 AM
Modify the write acl on category and sub category tables, add itil user role in list of roles sections

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-30-2016 06:50 AM
Hi Girish,
In general this is not a good practice. Categories & Subcategories for Incident are something that may change gradually over time, but should not be changing frequently enough that ITIL users need to update them. Additionally, ITIL users will rarely have a solid grasp of best practices when working with choices, which will most likely result in less than desirable options being added. Finally, the choices for Category and Subcategory live in the Choice[sys_choice] table, along with all other choices. As such you would have to write very specific ACLs to grant access to only these records, in addition to creating a module for users access the table to add/update records.
As an alternative to giving ITIL users direct access, I would recommend building a spreadsheet that they can populate with the new categories and subcategories that they provide to your admin team that then imports that spreadsheet. This will allow admin's to review the document prior to loading the new choices and ensure that best practices are being adhered to.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-30-2016 07:03 AM
As balaji said you can do this by giving read and write access to sys_choice table. If you are going in this route make sure to create a module for ITIL users and expose only category and subcategory choice values so that they won't be updating the other choice values. Also, this involves a lot of training to end users especially for creating a sub category values which are dependent on catagory.
Another method is to create a new table and use those values for category and sub category fields. In this method you are not just giving access to newly created table.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-30-2016 07:09 AM
Look at the following from the Wiki it should let you do what you want
The personalize_choices security role can be used to let non-administrators modify the options for Choice elements on all tables. If more granular control is desired, you can also create a custom ACL (security rule) governing the personalize_choices operation either for a particular field or for all fields (.*) on a particular table. However, access to the personalize_choices operation on a particular field does not confer the ability to add new choices for that field. To be able to create new choices for a particular field, two ACLs are required:
- An ACL that grants personalize_choices access for that field.
- An ACL that grants create access to the Choice table (sys_choice).
- An ACL granting create access to the hris_admin role on the Choice (sys_choice) table.
There are predefined ACLs granting both types of access to the personalize_choices security role, for all fields on all tables. The personalize_choices security role also has read, write, and delete access to the sys_choices table. However, this additional access is not required when making just the Personalize Choices functionality available on a granular basis.