Best practices for creating a system user for "Run As" in Scheduled Jobs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 05:54 AM
Hi everyone,
We currently have more than 170 Scheduled Jobs running in our instance that do not have the Run As field populated. We are looking to improve this setup by assigning a proper system user to these jobs.
Could you please share your recommendations or best practices for:
- Creating a dedicated system user account to be used in the Run As field?
- Permissions or roles that this user should have?
- Any security or audit considerations when using a system account for Scheduled Jobs?
Thanks in advance for your advice!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 06:05 AM
Usually we keep Run as -> System Administrator
Even if you create a dedicated user account you will have to ensure proper role is give
If that job is doing admin level tasks, then you need to give admin role
Yes if you have a dedicated user account or System Administrator in "Run as" it helps for debugging and troubleshooting and auditing as well.
If my response helped please mark it correct and close the thread so that it benefits future readers.
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 06:06 AM
We run our scheduled jobs as the Administrator, System (admin) account.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 06:09 AM - edited 06-26-2025 06:18 AM
čau @Ivo Franec,
some of the good practice might be:
- user account properties:
- the user should be marked as following:
- "web service access only = true",
- "internal intergation user = true"
- the user should be marked as following:
- naming convention:
- name the users to easily understand and see who made the job,
- e.g. AD User Provisioning, Mulesoft Collector, CMDB Handler, Approval Auto Rejection
- the more detailed the better,
- avoid using too general names "External system update",
- re-use the user accounts where applicable.
- access rights and roles:
- avoid granting full admin,
- instead grant for example application related admin only - example: I have a custom app called "Sandstorm" and it has automatically created sandstorm_user and sandstorm_admin, so for this you could allow the sandstorm_admin instead of the system admin
This is what goes on my mind, let me know if this makes any sense to you or if you need any more details on anything above.
/* If my response wasn’t a total disaster ↙️ ⭐ drop a Kudos or Accept as Solution ✅ ↘️ Cheers! */
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 06:23 AM
Your 'run as' needs to have sufficient roles to do what they need to do. It will be a huge maintenance nightmare if you decide to get every job to run on the least amount of roles. Just use the 'sys admin'.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark