Auto-populate feature does not work for non-itil users

[Eduardo Robali1]

We are using the Auto-populate feature for some variables within a catalog item and are noticing that when the requestor is a non-itil or fulfiller user, the variables that should auto populate based on the dependent question do not auto populate. When the same action is taken by a ITIL user or fulfiller, these variables do populate.  In the below example, the request is being made by an end-user in the ESC, company & manager should autofill based on the Requested for name. 

Below is the configuration for the auto-populate feature within the Company variable, the manager variable has a similar setup.

[jMarshal · Accepted solution]

You probably have those values restricted on the company table via AC. I'm quite sure that it is restricted to itil role oob, when you subscribe to ITSM.

The company table isn't oob open to the person who that data "belongs to", the way a RITM would be for the person who is "requested for".

Edit the read AC for the company table, to be less restrictive and see if that helps...from there you can improve your AC to be as restrictive as needed, while still supporting your auto-populate configurations.

https:// <INSTANCE-NAME>.service-now.com/now/nav/ui/classic/params/target/sys_security_acl_list.do%3Fsysparm_query%3DnameSTARTSWITHcore_company%26sysparm_first_row%3D1%26sysparm_view%3D%26sysparm_choice_query_raw%3D%26sysparm_list_header_search%3Dtrue

[jMarshal · Accepted solution]

You probably have those values restricted on the company table via AC. I'm quite sure that it is restricted to itil role oob, when you subscribe to ITSM.

The company table isn't oob open to the person who that data "belongs to", the way a RITM would be for the person who is "requested for".

Edit the read AC for the company table, to be less restrictive and see if that helps...from there you can improve your AC to be as restrictive as needed, while still supporting your auto-populate configurations.

https:// <INSTANCE-NAME>.service-now.com/now/nav/ui/classic/params/target/sys_security_acl_list.do%3Fsysparm_query%3DnameSTARTSWITHcore_company%26sysparm_first_row%3D1%26sysparm_view%3D%26sysparm_choice_query_raw%3D%26sysparm_list_header_search%3Dtrue

[Robbie · Accepted solution]

Hi @Eduardo Robali1,

Funnily enough, I was working on a very similar post just yesterday. 

Short answer, users without certain roles can access the [sys_user] record but not its related fields - in your case, the company field.

I've provided a link to where James has provided the solution, but to summarise, here are your options:

• If the 'company' (or other variables) are used only for triggering some process (e.g. approval or task), remove/hide the variable from the catalog item and retrieve the company value with the workflow/flow or other processes that require it.
• Create a custom ACL
• Try the the onChange Script and Script Include option I provided on the post.

To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Helpful.

Thanks, Robbie

Similar question: https://www.servicenow.com/community/virtual-agent-forum/catalog-request/m-p/2878034#M6117

[Eduardo Robali1]

Thank you for the quick replies. Seems this should be something ServiceNow should be aware off and not be a problem that requires a custom ACL since we are using an OOTB feature.