SwissNowThe real risk in ServiceNow Flow Designer: elevated identity, no filter
A flow that runs as an admin isn't automatically a problem. A flow that runs as an admin on every record, with nothing narrowing which ones - that's the pattern worth checking.
How this actually shows up
Flow Designer makes it easy to reach for an elevated run-as identity when a flow needs to touch records the triggering user can't - and easy to never revisit whether that's still the right call.
Elevated run-as with no trigger condition
Fires on every create or update on the table, not just the specific records it was actually built for.
Broad table scope for a narrow use case
Triggered on an entire table when the real need was only ever a single field's change on a subset of records.
Credential sprawl in Connections & Credentials
More stored credentials than active integrations - nobody's gone back to prune the ones nothing references anymore.
Subflows inheriting elevated identity without re-evaluation
A subflow runs with whatever identity its parent had, whether or not the subflow's own actions actually need it.
How to check
The flow's name tells you what it's supposed to do. Its trigger tells you what it actually does.
Read the trigger, not just the flow name
A flow's real configured table and filter condition live in its trigger definition, not in how it was named when it was built. Reading the actual condition - or confirming there isn't one - is the only reliable way to know what a flow really reacts to.
Check run_as on every active flow, not just the ones you remember building
Elevated run-as flows accumulate the same way over-permissioned roles do - one at a time, each individually justified, rarely revisited as a set.
Patterns worth reviewing first
- Active flows with an elevated run-as identity and no filter conditionThe combination that matters - either alone is common and often fine; together, worth a second look.
- Flows triggered on a whole table when only specific fields matterFiring far more often than the flow's actual logic needs.
- Stored credentials with no active connection referencing themLeft over from an integration that was retired, or never quite finished.
- Flows nobody's opened since the person who built them leftNot wrong by default - but nobody on the current team can currently explain why it's configured the way it is.
The manual version doesn't scale
Checking this properly means opening every active flow, reading its real trigger configuration, and judging whether the run-as identity actually matches the risk of what it can touch - then doing it again the next time a flow is added or edited. On an instance with hundreds of active flows, that's simply not something anyone reviews continuously by hand.
Running this review continuously, automatically
Our own platform, neo.ai, reads every active flow's real trigger condition on a schedule and judges whether an elevated identity is actually appropriate given what the flow does - not just whether one is configured. It's one of seven categories it watches across a ServiceNow instance.