Hi
Was trying to create incident in ServiceNow via the below API curl call but the incident description field is not updated for regular users, it works for admin though! There was an access control (ACL) for description which I deleted but still the description field is blank when incident is created.
Curl Call -
curl --location --request POST 'https://dev80009.service-now.com/api/now/table/incident' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic dGVzdDp0ZXN0' \
--header 'Cookie: BIGipServerpool_dev80009=2609075978.55360.0000; JSESSIONID=03AB5C528F99C3FE4CA1954E3EAA8747; glide_user_activity=U0N2MzpVb1RSTjJDSG9ZOEJTQnR2eWFIQ0tqNmRROFZCcVQzTTpPRWpoYm1jZVBML28vWktCT0E5Y2VYclNac0pldXpsQmpINlBLV251ZktrPQ==; glide_user_route=glide.e0bd65849cb91a6b8a16a2533b5fca6d' \
--data-raw '{"short_description":"short test","description":"test"}'
Can someone suggest what should be done here?
ACL which was deleted -
NO ACL for description -
Postman result with description blank -
Hi,
Create a new ACL on incident description field as below and your issue will be resolved.
This will allow your service account to update the incident description without any role restriction.
Now, talking about the situation where OOB ACL (which you deleted) is existing.
In that case you could have done by creating another write ACL on Incident Description field with condition as below:
Kindly mark my answer as Correct and Helpful based on the Impact.
Regards,
Alok
Hi,
So if there is no ACL for table.field, but the table is extended from another table, and that field derives from this other table...then it will use that parent table's ACL for that field (if applicable).
With that said, there is an ACL for task.description which requires: itil or task_editor roles to edit it.
So either create a new write ACL for the incident table.description and adjust role and/or condition as appropriate or consider revising this one that is out of box, but I would suggest against doing that.
You can also debug security rules yourself as that end-user (impersonate) and see that they'd be unable to write to it: https://docs.servicenow.com/bundle/quebec-platform-administration/page/administer/contextual-securit... and why.
Please mark reply as Helpful/Correct, if applicable. Thanks!
