I tried creating a user with "Web service access only" enabled in ServiceNow
This page has been translated by machine translation. View original
Introduction
When creating users (service accounts) for external system integration in ServiceNow, there are cases where you want to restrict access to API-only without allowing interactive UI login.
That's where the "Web service access only" field in the sys_user table comes in. This article introduces how to enable this field.
When actually working with it, I found that "Web service access only" is not a field you can directly check on the form, but rather a value that is automatically determined based on the Identity type value. This article introduces 3 methods for enabling it, taking this relationship into account.
What is Web service access only
Web service access only is a field in the sys_user table. When enabled, the user cannot log in through the interactive UI and is restricted to API-based access only. This is an appropriate setting for users intended for external system integration.
In the official documentation, it is described as a Non-Interactive Sessions feature.
In the verification environment used this time, this field already existed in the sys_user table.
Relationship with Identity type
The sys_user table also has a field called Identity type, which classifies whether a user is a real person or some other kind of principal. In the official documentation, it is described as follows.
Identity type Select the user identity type based on the user:
- Human - Select this for a real person, such as an employee, customer, or admin.
- Machine - Select this for a non-human system or device, such as a server, application, or service account that makes automated requests.
The Web service access only check box is automatically enabled when you select Machine in the Identity type field. The Web service access only check box is automatically disabled when you select Human or AI.
Select Identity type based on the type of user. Select Human when representing a real person such as an employee, customer, or administrator. Select Machine when representing a non-human principal such as a server, application, or service account that makes automated requests. When you select Machine in Identity type, the Web service access only checkbox is automatically enabled. When you select Human or AI, it is automatically disabled.
https://www.servicenow.com/docs/r/platform-administration/user-administration/t_CreateAUser.html
Prerequisites
According to the official documentation, the role required to create a user is user_admin. For this verification, the default administrator user (admin) of a PDI was used.
Three Methods to Enable
In this verification, I confirmed that Web service access only can be enabled using any of the following 3 methods.
Method 1: Create a new user with Identity type set to Machine
Search for "Users" in the Filter Navigator and open it from System Security > Users and Groups > Users. Click New on the list screen that appears, and enter the User ID, First name, and Last name. Change Identity type to Machine and then click Submit.
New User record creation screen
When saved in this state, the value of Web service access only will also automatically become true.
Method 2: Change the Identity type of an existing Human user to Machine
If there is already a user created with Identity type set to Human, open the record, change Identity type to Machine, and click Update.
State where Identity type is Human. Web service access only is grayed out
At this point, the Web service access only checkbox itself is grayed out and cannot be clicked directly. When I tried changing Identity type to Machine, the checkbox remained grayed out, but the value automatically switched to true.
In other words, this field is not something the user directly operates on the screen, but rather a field that is automatically determined by the system based on the value of Identity type — essentially read-only.
Method 3: Set directly via Background Script
If changing Identity type on the form is difficult, or if you want to process multiple records with a script, you can also update it directly from Background Script. Search for "Scripts - Background" in the Filter Navigator and open it from System Definition > Scripts - Background. Run the following script. The user_name column of the sys_user table corresponds to the User ID on the screen. Replace the target User ID part with the User ID of the target user.
var gr = new GlideRecord('sys_user');
if (gr.get('user_name', 'target User ID')) {
gr.web_service_access_only = true;
gr.update();
gs.print('Updated: ' + gr.user_name + ' / web_service_access_only = ' + gr.web_service_access_only);
}
Paste this script as-is into the Scripts - Background input field.
State with the script pasted into Scripts - Background. Run script will be executed after this
When executed, the log will output "Setting Identity type to Machine as web_service_access_only is true". When you try to directly set web_service_access_only to true, the Business Rule changes Identity type to Machine to maintain consistency — this is the reverse behavior compared to Methods 1 and 2.
Background Script execution result. The log shows that Identity type has changed to Machine
Verifying on the List Screen
By opening the user list screen and adding the "Web service access only" column through the column settings, I was able to confirm that the value for the target user was true.
Screen confirming that Web service access only is true in the user list
Setting a Password and Roles
As needed, set a password using "Set Password" and assign roles from the "Roles" related list.
Summary
I tried creating a user with Web service access only enabled in ServiceNow.
This field is not something you can directly click on the form — it is a value that the system automatically determines based on the Identity type value. To enable it, you can either set Identity type to Machine when creating a new user, change an existing user's Identity type from Human to Machine, or set the value directly using Background Script.
When creating service accounts for external system integration, it is smoother to think in terms of Identity type rather than trying to operate the checkbox directly.