Creating a custom role to update incidents with a specific field value
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-14-2025 04:53 PM
I was told that this was a "sys admin 101" question so I'm posting here. Please let me know if I should move this elsewhere.
I am trying to create an API integration with service now where the API account ONLY has permission to update incidents that have a single assignment group. Using elevated permissions, I have created a custom role with several ACLs and a user with that role. My tests show that I can read the incident table to see the incidents I want to update, but when I try to update any of the incidents the API returns 200, but nothing is updated. If I test using “itil user”, everything works, which suggests that I do not have enough or the correct permissions. Creating incidents is a future goal, but not my current goal.
I am trying to update the following fields:
- Short description
- Description
- Correlation ID
- Additional comments
- Work notes
- Attachments
Note: my integration will update the fields correctly if I use “itil User”, which has the role “ITIL”. The user with the customer role (and ACLs below) does not update the fields.
ACLs for the my custom role:
- incident(read)
- incident(write)
- sys_db_object(read)
- sys_db_object.*(read)
- sys_dictionary(read)
- sys_dictionary.*(read)
As an example, the incident ‘write’ ACL is below. My preference is no scripting, since the administrator does not know how to script and does not always have access to a developer.
So my questions are:
1. Why does this work with ITIL and not my ACL setup?
2. Am I missing ACLs, if so, which ones will allow me to update those fields
3. Is it possible to do what I want w/o scripting?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-14-2025 05:46 PM
Hi @snow2p,
It looks like you have ACLs on fields and not only to tables for itil roles.
Example:
As you mentioned you have ACLs with the custom role for:
- incident(read)
- incident(write)
- sys_db_object(read)
- sys_db_object.*(read)
- sys_dictionary(read)
- sys_dictionary.*(read)
If you have any other write ACLs on fields with "itil/any other" role for:
- incident.short_description
- incident.description
- incident.correlation_id
- incident.comments
- incident.work_notes
It won't work until unless you add the custom role to these ACLs or create new ones for these fields with the custom role. (I would recommend creating new ones for the OOTB existing ACLs)
Note that for sys_attachment. This is another table. Hence, you can use the OOTB Attachment API which provides all the methods you would need to manage your attachments. I would not recommend creating a custom method to manage attachments as this would require ACLs for the sys_attachment and heavy testing to ensure attachments are working fine for other tables and roles.
If you found this helpful, please hit the thumbs-up button and mark as correct. That helps others find their solutions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-17-2025 08:11 AM - edited 03-17-2025 02:55 PM
Hi Medi,
Is there no easier way to grant write access to all fields in the incident table than to create individual ACLs as you suggested? i.e. while I use incident-->write to allow writing, will incident.*--> write all writing all fields? I will likely need to also update state, priority, and attachments.
I ask since I created the ACLs for the individual fields as suggested and the top 3 worked, where I can update those fields, but work_notes will not update. Basically, the two ACLs below are not enabling the incident update. It feels like I'm on the path to progress but am blocked.
- incident.work_notes
Another way to ask the question - how does the role itil allow writing to all the incident fields? As mentioned before I want to act like a user with itil role on the incident table, but ONLY when assignment group = <group created for integration>.