Use dedicated service accounts instead of the built-in admin or guest user for scheduled jobs and integrations - Support and Troubleshooting

Use dedicated service accounts instead of the built-in admin or guest user for scheduled jobs and integrations Issue .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Many ServiceNow instances rely on the built-in admin account as the Run as user for scheduled jobs and as the credential for inbound or outbound integrations. This creates operational risk and does not follow the principle of least privilege.

Using a shared built-in account for automation means that any issue affecting that account — such as a password reset, a lockout caused by failed login attempts, role changes, or deactivation — will simultaneously disrupt every scheduled job and integration that depends on it.

Symptoms .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Organizations using shared built-in accounts for automation commonly observe:

Multiple scheduled jobs failing at the same time with messages such as "[Job Name] not executed. User admin is locked out" . Integrations breaking unexpectedly after a password rotation on the admin account. Difficulty auditing which integration, script, or job performed a specific action, because all activity is attributed to the same shared user. Over-privileged automation, where jobs requiring only read access or a specific domain of functionality are executing with full administrator rights. No clear ownership mapping between a workload and the identity that runs it. Facts .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } A service account is a dedicated, non-human user created specifically to run automation, scheduled jobs, or integrations. The principle of least privilege means granting an account only the minimum roles required to perform its function — not the admin role by default. Scheduled jobs in ServiceNow run under the user specified in the Run as field. If that user is inactive, locked out, or lacks the required role, the job will not execute. The Web service access only flag restricts a user to API-based access and prevents interactive UI login. This is the recommended setting for accounts used exclusively by integrations. Setting Identity Type = Machine on a user record automatically enables the Web service access only flag and clearly identifies the account as a non-human identity in platform reports and dashboards. Assigning roles through a group, rather than directly to the user, makes role management easier to audit and maintain over time. Release .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All supported ServiceNow releases.

Cause .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This is not a defect — it is a configuration and design pattern recommendation. The built-in admin accounts are general-purpose platform accounts and were never intended to serve as the identity for production automation or integrations. Using them for this purpose:

Concentrates operational risk into a single shared credential. Grants excessive privileges to workloads that rarely need full administrator rights. Makes it difficult to attribute actions to a specific integration or job. Couples unrelated workloads together, so an issue with one can cascade to all. Resolution .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Replace the built-in admin accounts used by scheduled jobs and integrations with dedicated service accounts that follow the principle of least privilege. The steps below describe the recommended approach.

Step 1: Inventory scheduled jobs running as admin

Navigate to System Definition > Scheduled Jobs. Add the Run as column to the list view if it is not visible, then filter where Run as = System Administrator (or admin ). For each job, capture:

Job name and class Schedule / frequency Tables and operations the job reads from or writes to Business owner of the job, where known Step 2: Determine minimum role requirements

For each job or integration identified, review the script or configuration to determine exactly which tables and operations it needs. Use this to identify the narrowest role set that will allow the workload to run. For example:

Performance Analytics data-collection jobs typically require pa_admin or pa_data_collector role. Catalog-related automation may only need catalog_admin . Reporting jobs may only need report_admin plus read access on specific tables. Group related workloads that share the same role requirements so that a single service account can serve a logical group of jobs.

Step 3: Create dedicated service accounts

For each logical group, create a new user with the following configuration:

User ID: Use a clear naming convention that identifies the purpose, for example svc_appsec_collector , svc_daily_data_mgmt , or svc_integration_ . Active: true. Password: A strong, unique password per organizational standards. Store in a secrets manager, not in documentation. Web service access only: Enable for accounts used exclusively for API or integration access. For accounts used as Run as for internal scheduled jobs, test first, as some platform jobs may require this flag to be unchecked. Roles: Assign only the minimum roles identified in Step 2. Avoid assigning the admin role directly. Assign roles through a group rather than directly to the user where possible, to simplify auditing and maintenance. Identity Type: Set to Machine, which automatically enables the Web service access only flag and clearly marks the account as non-human. Step 4: Update scheduled jobs and integrations

Update the Run as field on each scheduled job to point to the new service account instead of System Administrator . For integrations, update the stored credentials in the relevant Connection & Credential Alias or integration configuration.

Step 5: Test and validate

After updating the Run as field, manually trigger each job and confirm successful execution. Review the job's execution history and system logs for access errors. If a job fails due to insufficient permissions, grant only the specific missing role to the service account and re-test. Avoid the temptation to fall back to the admin role.

Step 6: Document and monitor ongoing governance

Maintain a register of service accounts, their purpose, their owner, and their assigned roles. Rotate service account passwords on a defined schedule aligned with organizational security policy. Periodically review service account activity and remove or disable accounts that are no longer in use. Consider creating a notification that alerts operations teams if a service account becomes locked or inactive, so that remediation can begin immediately. Related Links .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } KB1933421 — Service Account Management Best Practices: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1933421 KB0813159 — How to enforce strict REST API security: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0813159 KB0793963 — REST API authentication requirements for inbound requests: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0793963 KB2252196 — Integration Accounts without Web Service Access Only Flag enabled: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2252196 KB0792532 — Web service access only user behavior: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0792532 KB2420837 — Web service access only field is read-only (Identity Type field): https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2420837 Community — User account or service account? What to use for web service tasks: https://www.servicenow.com/community/in-other-news/user-account-or-service-account-what-to-use-for-web-service/ba-p/2286977 Community — Best practices for creating a system user for Run As in Scheduled Jobs: https://www.servicenow.com/community/developer-forum/best-practices-for-creating-a-system-user-for-quot-run-as-quot/t-p/3301401 Community — Recognising the types of users that access your instance (Identity Type field): https://www.servicenow.com/community/in-other-news/recognising-the-types-of-users-that-access-your-instance/ba-p/3399656