Best practices for creating a system user for "Run As" in Scheduled Jobs

Ivo Franec
Tera Contributor

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!

4 REPLIES 4

Ankur Bawiskar
Tera Patron
Tera Patron

@Ivo Franec 

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.

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader

Brad Bowman
Kilo Patron
Kilo Patron

We run our scheduled jobs as the Administrator, System (admin) account.

GlideFather
Tera Patron

č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"

KamilTEL_0-1750943169584.png

 

  • 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 Manders
Mega Patron

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