Run as System property in Flow designer

[maliksneha9]

Hi everyone,

We have recently started using Flow Designer in ServiceNow and had a question regarding “Run As: System User” in flows.

What are the main cons or risks of using System User? From what we understand, it bypasses ACLs and user permissions, but we’d love to hear real-world experiences, especially around security, auditing, or unexpected behavior.

Also, what precautions or best practices do you usually follow when using it?

Any insights or lessons learned would be really helpful. 

[Tanushree Maiti]

Hi @maliksneha9 

System user

• Runs as System
  
• Updates appear as done by System
• Does not evaluate Users roles/access when running the Flow

User who initiates session

• Run by user who initiates the session
• the system limits flow actions by user ACL restrictions
• Run As settings for a flow does not apply to child subflows.

Refer: Create a flow 

Best Practices- we Follow- Run as System user if the flow having subflow ( integration related flow)

[Ken tang]

hey 

The biggest real-world pain point with System User is the audit trail. When a flow runs as system, the sys_updated_by on records just shows "system" - which is fine for pure background automation, but becomes a headache when auditors or your security team asks "who changed this?" Might be an issue for regulated industires

The other thing that trips people up is assuming System User is all-powerful - it's not. There are specific cases, like certain CMDB table lookups, where system user will fail because it doesn't have the right role-level permissions. You can't assign roles to the system user directly, so when a lookup fails in prod, you're left wondering why since it all workd in dev (where your admin session had everything).

I'd honestly default to "User who initiates session" + "Run with roles" over System User in most cases. You get scoped elevation without throwing away the audit trail. Use System User only for fully automated background processes that have zero human trigger - scheduled jobs, integration polling, that kind of thing. And one sneaky gotcha: that Run As setting does NOT cascade to subflows, each one needs to be set independently.