What happens to scripts when "Run As" user is Inactive or Locked Out? Seeking Best Practices

[saint]

Hi Experts,

I've observed a recurring issue where scripts or flows configured to run under a specific user account begin to fail once that user becomes inactive or is locked out of ServiceNow. These failures typically occur silently unless error handling has been explicitly built to catch such conditions.

I'm trying to understand what happens in the backend when this occurs. Specifically:

• What mechanisms cause the script to fail when the user is inactive?
• Are there any logs or indicators that can help identify these failures?
• What are the best practices to prevent or mitigate the impact of such scenarios?

Additionally, I’d appreciate any guidance on how to assess the potential impact of these failures and ensure it's kept to a minimum.

@Mark Manders @Ankur Bawiskar 

Thanks in advance for your insights!

[Nikhil Bajaj9 · Accepted solution]

As per my understanding - When a "Run As" user for a scheduled job or script is inactive or locked out in ServiceNow, the script will fail to execute. This is because the system cannot authenticate the user to run the script. The specific behavior may vary based on the script type and platform. Best Practices:- 

1. Always ensure the "Run As" user is active and has the necessary permissions to execute the script. 
2. Create a specific user account for running scripts and scheduled jobs. This account should have the minimum necessary roles and permissions and should be regularly monitored for activity and security. 
3. Scripts should include error handling to gracefully manage situations where the "Run As" user is inactive or locked out. This might involve logging the error, sending a notification, or attempting an alternative action.
4. Leave Run as  - blank so that it will be run as - System user.

 As you correctly said- it is silent till the time, we realize that job is not running and we ar enot getting the expected output.

If my answer helped you, please mark -solution accepted.

Regards,

Nikhil Bajaj

[Nikhil Bajaj9 · Accepted solution]

As per my understanding - When a "Run As" user for a scheduled job or script is inactive or locked out in ServiceNow, the script will fail to execute. This is because the system cannot authenticate the user to run the script. The specific behavior may vary based on the script type and platform. Best Practices:- 

1. Always ensure the "Run As" user is active and has the necessary permissions to execute the script. 
2. Create a specific user account for running scripts and scheduled jobs. This account should have the minimum necessary roles and permissions and should be regularly monitored for activity and security. 
3. Scripts should include error handling to gracefully manage situations where the "Run As" user is inactive or locked out. This might involve logging the error, sending a notification, or attempting an alternative action.
4. Leave Run as  - blank so that it will be run as - System user.

 As you correctly said- it is silent till the time, we realize that job is not running and we ar enot getting the expected output.

If my answer helped you, please mark -solution accepted.

Regards,

Nikhil Bajaj

[Ankur Bawiskar · Accepted solution]

@saint 

Flows can either run as "System User" or "User who initiated the session"

If it's "System User" then we need not worry.

Few practices we can follow

-> wherever possible use System User in flow

-> periodically review the flows

-> maintain a document of each flow and it's config so that it becomes easier to track, maintain, debug in future

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Its_Azar]

Hi there  @saint 

the platform will stop executing actions that require that user’s context because authentication and role checks fail at runtime. This means any GlideRecord operations, API calls, or business rules tied to that user’s security profile won’t proceed, Best practice is to avoid tying automation to personal accounts — instead, create a dedicated integration/service account with a non-expiring password, required roles, and exclusion from inactivity locks. Regularly audit scheduled jobs, flows, and “Run As” settings to confirm they’re mapped to such accounts, and set up alerts for execution errors.

If this helps kindly accept the solution thanks much

[saint]

Thanks for the response Azar, I'm curious about the non-expiring password you mentioned. What's that.

FYI, I'm working on already built system, so some of the scripts were following the user accounts rather than system user configuration. I will make sure to follow all the above suggestions and advices to clean up this instance. Thank you so much.