Failed API level ACL Validation trying to accessing table api (scoped application)

[nthumma]

<response>

    <error>

<message>User Not Authorized</message>

<detail>Failed API level ACL Validation</detail>

</error>

<status>failure</status>

</response>

I am getting above error when i am trying to access table api(https://my.service-now.com/api/now/table/table_name) scoped application (fuji). it works fine for other tables which are not scoped to a application.

any thoughts?

[lott_caskey · Accepted solution]

The default runtime access for new scoped applications does not allow for access from web services.

http://wiki.servicenow.com/index.php?title=Application_Access_Settings#Default_Runtime_Access_Permis...

Enable Web Services access to the scoped application table.

1. Navigate to System Applications -> Applications
2. Click Edit on your Application
3. In the Tables related list, click the desired table.
4. Click the Application Access tab
5. Change Accessible From to "All Application Scopes"
6. Check "Allow access to this table via web services"
7. Save
   

[nthumma]

many thanks it worked

[Ak Islam]

Hi there,

I have exactly same error while accessing an staging table via REST Api. here is the error:

<Fault xmlns="http://192.168.10.71/api/now/import/u_inbound_incident">

    <error>

          <detail>Failed API level ACL Validation</detail>

          <message>User Not Authorized</message>

    </error>

    <status>failure</status>

</Fault>

I have followed exactly same instructions provided by Lott Caskey. still no luck. Just to give an idea, the web service user has itil, itil admin, rest_service and SOAP role.

"u_inbound_incident" is a staging table that has no ACL on it but its parent table has 4 different ACL( OOTB System Import Set Table)

Staging table is not part of any application. Do I have to associate the table with Application???

Can anyone please help me on this??

Thanks in advance

[jberk]

Hi,

I know this is a bit old but I noticed it while searching for something else and I think we had the same issues. The user needs to have the import_set_loader role if the staging table is doing what it sounds like is inbound incident imports.

-JB