- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
an hour ago
Watch ServiceNow Foundations video series
How Security Works in ServiceNow
Picture this. Your boss calls the customer who's been testing your new portal and nothing works. They can't see anything. The whole thing looks broken. Panic sets in on both sides of the call.
Then it hits you. It worked fine for you because you're an admin. You never tested it as a regular user. And now you get to carry that experience with you forever as a cautionary tale.
Yeah. Let's make sure this doesn't happen to you.
Security in ServiceNow controls who can do what with data. Get it wrong and one of three things happens: users can't use your app (business impact), users can see data they shouldn't (data breach), or you spend hours debugging "why can't I see this" (productivity killer). Understanding how it works helps you build apps people can actually use while keeping sensitive data where it belongs.
ACLs: The Gatekeepers
Let's say you're trying to view an incident record. ServiceNow checks this in layers.
First, it checks the table level. Can you access the incident table at all? It looks at the table access control list (ACL) to see if any rules grant you access. If they do, the gate opens. If not, that incident doesn't exist as far as you're concerned.
Once you pass the table check, ServiceNow goes field by field. Can you see the description? Checks the field ACLs. Yes, you can. What about the caller's social security number? Checks the field ACLs. Nope. That field just disappears from the form. This is how ServiceNow shows users the whole record or just the parts they need to see.
So what's happening inside each ACL check? ServiceNow evaluates three things, in order:
- Roles. Do you have the right role? If yes, move on. If not, stop here.
- Condition filter. Maybe you can see this record, but only if the incident is assigned to your group.
- Script. Custom logic that might check other records, call APIs, or evaluate whether it's the first Tuesday after a full moon. It can get fancy.
All three must evaluate to true for the ACL to pass. And they're executed in that specific order because each one is progressively more expensive for the system to evaluate. Roles are a quick lookup, conditions require a filter evaluation, and scripts can do basically anything. This whole process runs for read, write, create, delete, and a bunch of other operations worth exploring on your own.
Application Scope: Security Between Apps
So that's what users see. But what about your apps?
Application scopes create security boundaries between applications. When your app needs to access another scope's resources, there are a few layers involved.
First, tables control their own access. Every table has application access settings, checkboxes that say "other scopes can read this" or "other scopes can write to this." If those aren't checked, other apps can't touch that table. Full stop.
Second, your app tracks what it's accessing through cross-scope privileges. When you're developing and runtime access tracking is turned on, ServiceNow automatically creates records showing "this app is accessing that table in that other scope." These privileges get packaged with your app when you deploy it.
Third, individual resources can have their own restrictions. Tables, script includes, even business rules can be set to require approval before other scopes can call them. This is common with sensitive data like HR applications.
The pattern is straightforward: access requires coordination. The table has to allow it, your app has to declare it, and individual resources might add extra restrictions on top.
The Lesson From My UAT Disaster
Test from every role and persona. Not just admin.
Create test users with the actual roles your end users will have. Test every operation: read, write, create, delete, for every role. And test the different ways data gets accessed. There are specific ACLs for queries and reports that can accidentally expose data even when standard read access is locked down.
That one catches people off guard more often than you'd think.
