Creating a ServiceNow User for the CLI

Recommended roles and user setup for running sn execute, sn validate, and sn test against a ServiceNow instance.

Using a dedicated CLI user rather than your personal admin login gives you clean audit trails, a tightly scoped revocation surface, and confidence that automated runs don't carry your full session context.

For development PDI instances it's fine to register your personal admin user. For shared team environments or any instance that connects to production data, a dedicated service account is strongly recommended.

Create the user

Navigate to: *All > System Security > Users > New*.

Fill the required fields (User ID, First/Last Name, Email). Set Active to true. The user does not need a personal password if you plan to use a REST API Key or OAuth grant — for basic auth you will set a password and pass it to sn instance add.

Roles by use case

*For sn execute on most skills:* The admin role covers everything. For a least-privilege bundle, assign the roles the specific skills require — see each skill's reference page for the tables it writes. A curated minimal-role bundle is tracked as a follow-up task in the engineering roadmap.

*For REST API Key setup:* api_service_admin, adaptive_auth_policy_admin.

*For OAuth Client Credentials setup:* oauth_admin, mi_admin, or admin.

The admin role grants full write access to all tables and scripts. For production environments, scope this to the minimum required roles for your workflow.

Register the user with the CLI

Once the account is created and has the right roles, register it:

sn instance add default \
  --url your-instance.service-now.com \
  --user cli_automation \
  --pass - \
  --default

Then verify: sn get sys_user sysparm_limit=1.