ServiceNow Application Security: Understanding What Actually Controls Access
Security is one of the areas of ServiceNow development where a small misunderstanding can produce a very large problem. A developer may know that ACLs control access, know that roles are involved, and know that client-side scripts can hide fields, yet still have an incomplete picture of how ServiceNow actually decides whether a user can perform an operation. The important part isn't memorizing that "ACLs are security" and moving on. For application development, you need to understand what ServiceNow evaluates, what level of access is being requested, how multiple security rules interact, and where a particular control belongs.
That becomes especially important when building scoped applications. A custom application may have its own tables, roles, scripts, UI, and data relationships, but it still operates inside the broader ServiceNow security model. Users can arrive through different interfaces, records can be accessed through different mechanisms, and server-side code can perform operations that are not directly associated with a form. If the security design depends on the user seeing a particular screen or clicking a particular button, the application is relying on the wrong layer.
A useful way to approach ServiceNow security is to stop thinking about "hiding things from users" and start thinking about authorizing operations against resources. Once that distinction is clear, the roles, ACLs, conditions, scripts, field-level controls, application scopes, and other mechanisms begin to fit together much more logically.
What Is ServiceNow Actually Protecting?
Before getting into ACL configuration, it helps to understand what an access decision is actually about.
A user isn't simply asking ServiceNow:
"Can I use this application?"
They may be asking to read a particular record, create a new record, update an existing record, delete a record, or access a particular field. Those are separate operations, and ServiceNow can secure them independently.
At the table level, the basic operations are:
-
Create — Can the user create a record?
-
Read — Can the user view a record?
-
Write — Can the user modify a record?
-
Delete — Can the user delete a record?
Field-level security introduces another important distinction because a user can potentially have access to the record while being restricted from reading or modifying a particular field.
That gives you a much more useful mental model than simply asking whether a user "has access."
For example, suppose an employee can read an equipment request but cannot modify it. That is different from an employee who cannot read the request at all. It is also different from an employee who can read the request but cannot see a confidential field on that request.
Those are different authorization decisions.
Roles Are Inputs to the Security Model
Roles are one of the first things developers encounter when securing ServiceNow applications, but it is important not to give them more meaning than they actually have.
A role represents a permission or capability that can be assigned to a user. ACLs can use roles as part of their access criteria, allowing an application to say, in effect, "users who possess this role are eligible for this operation."
That does not mean that assigning a role automatically grants unrestricted access to every table, record, and field associated with an application.
Consider an application with these roles:
-
x_company_request_user -
x_company_request_manager -
x_company_request_admin
You might design the application so that ordinary users can create requests, managers can work with requests belonging to their teams, and administrators have broader access.
The roles establish useful categories of users, but the ACLs still determine what those users are actually permitted to do.
This distinction matters because developers sometimes approach security backwards. They create a role called something like request_user, assign it to the appropriate people, and assume the application is now secure.
The role is only part of the design.
ACLs Are the Enforcement Layer
An Access Control List, or ACL, defines an access requirement for a protected resource and operation. When ServiceNow evaluates an access request, the relevant ACL rules become part of the authorization decision.
This is the mechanism that makes the security boundary real.
If the requirement says:
Users with the request user role can read requests.
the application can use a read ACL with the appropriate role requirement.
If the requirement says:
Users can update requests only when they belong to the assigned group.
the ACL can incorporate that additional condition.
If the requirement says:
Users can see the request but cannot see the confidential notes field.
the application can protect the field separately.
The important point is that the ACL isn't merely controlling what appears on a form. It is controlling whether the operation against the protected resource is authorized.
That distinction is the foundation for everything else in this topic.
Table ACLs and Field ACLs Are Not the Same Thing
Suppose your application contains a table called x_company_request.
A table-level read ACL can control whether a user is allowed to read records from that table.
Now suppose one of those records contains a field called confidential_notes.
The application may allow a user to read the record while denying access to confidential_notes.
That is why field-level ACLs exist.
You can therefore have a situation where:
The user can read the record.
but:
The user cannot read one particular field.
That isn't contradictory. The security model is simply operating at different levels.
The same idea applies to write access. A user could potentially have permission to update a record while being prevented from modifying a particular protected field.
When a CAD scenario distinguishes between an entire record and an individual field, pay close attention to that distinction because it often tells you which security level is being tested.
The Four Basic Operations Matter
When reading an ACL-related scenario, identify the operation before doing anything else.
If the user needs to create a record, you're dealing with create access.
If the user needs to view a record, you're dealing with read access.
If the user needs to change a record or field, you're dealing with write access.
If the user needs to remove a record, you're dealing with delete access.
A scenario can involve more than one.
For example:
Employees may create equipment requests and read their own requests, but they cannot modify or delete them after submission.
That isn't one security rule. It represents several distinct permissions:
-
Create access
-
Read access
-
Restricted write access
-
Restricted delete access
Treating all of that as "employee access to the table" would be far too broad.
Conditions and Scripts Serve Different Purposes
ACLs can use conditions and scripts to make authorization decisions more specific.
A simple role requirement may be sufficient when access depends only on who the user is.
A condition can be useful when access depends on information available directly from the record.
A script provides greater flexibility when the authorization logic requires more complicated evaluation.
Suppose every member of a fulfillment role can read every request. A role requirement may be enough.
Now change the requirement:
Members of the fulfillment role can read only requests assigned to their group.
The user's group membership and the record's assignment group now matter.
That is contextual authorization.
The important design principle is to use the simplest mechanism that accurately expresses the requirement. A developer shouldn't write a large script merely because ACL scripting exists. At the same time, forcing a complicated authorization requirement into a simplistic condition can make the rule inaccurate or difficult to maintain.
Security logic should be both correct and understandable.
Contextual Security Is Where Things Get More Interesting
Consider a table containing employee requests.
An ordinary employee should be able to see requests where:
requested_for = current user
A manager should be able to see requests where:
requested_for.manager = current user
A fulfillment agent should be able to see requests where:
assignment_group contains a group the current user belongs to.
An administrator may have unrestricted access.
Now the authorization decision depends on the relationship between the current user and the record.
The system isn't simply asking:
"Does this person have the request-user role?"
It is effectively asking:
"Does this person have the appropriate role and does this particular record satisfy the conditions under which that role grants access?"
That is why contextual security is so important in real applications. Business requirements frequently describe access in terms of ownership, assignment, department, manager relationships, or other characteristics of the current record.
A User's Role Does Not Tell You Which Records They Should See
This is worth emphasizing because it is one of the easiest mistakes to make when designing security.
Suppose 5,000 employees have the request_user role.
If that role simply grants read access to the entire request table, every employee can potentially see every request.
But the business requirement might actually be:
Employees can see only requests they submitted.
The role answers the question of who belongs to the category of users that may use the application.
The ACL needs to answer the question of which records that user is permitted to access.
Those are different dimensions of the security model.
When you see requirements containing phrases such as "their own," "assigned to them," "their department," "their manager," or "their group," you're usually looking at contextual access rather than a simple role-only decision.
The Client Is Not the Security Boundary
This is one of the most important rules in ServiceNow development.
A client-side script can change the behavior of a form, but client-side behavior should not be treated as the mechanism that protects sensitive data.
Suppose you want to prevent an employee from changing a field called salary.
You could make the field read-only with a Client Script or UI Policy.
That can improve the user experience because the field won't appear editable.
But if the actual requirement is:
Employees must not be allowed to modify the salary value.
the application needs server-side enforcement.
The reason is simple: the form is only one interface to the data.
A record might be manipulated through another interface or server-side mechanism. If the only restriction exists in the browser, the application has not established a reliable authorization boundary.
The correct mental model is:
Client-side controls improve the interface. Server-side controls enforce authorization.
You can and often should use both, but they have different jobs.
Hiding a Field Is Not the Same as Securing a Field
The same distinction applies to visibility.
Suppose a confidential field should not be accessible to ordinary employees.
Making the field invisible on a form doesn't automatically secure the underlying data.
The field could disappear from the interface while still being accessible through another mechanism if no appropriate server-side security control exists.
If the requirement is genuinely about protecting the information, the security model needs to enforce access to the field itself.
This is one of those concepts that seems obvious once you've heard it, but it causes a surprising amount of confusion during application development because the visible behavior of the form can make an application appear more secure than it actually is.
UI Actions Have the Same Problem
Imagine a custom application has a button called Approve Request.
Only managers should be able to approve requests.
You could configure the UI Action so that ordinary employees don't see the button.
That's useful.
It is also not the complete security solution if the approval operation itself needs to be protected.
The button controls whether the user is presented with the action.
The server-side authorization model needs to control whether the operation is actually permitted.
This principle applies broadly:
Removing an option from the interface is not equivalent to denying permission to perform the underlying operation.
Inheritance Can Make ACLs Less Obvious
ServiceNow tables can participate in table inheritance, and that matters when security is being evaluated.
Suppose you create a custom table that extends another table. The child table inherits characteristics from its parent, and the security model can therefore involve ACLs defined at different levels of the table hierarchy.
This becomes important when troubleshooting an access problem because the ACL that matters may not be located exactly where a developer expects to find it.
A developer looking only at ACLs created directly on the custom table can miss inherited security behavior.
The opposite can happen too. A developer may assume that because the parent table has an ACL, the child table will behave exactly as expected without understanding how the inherited access controls participate in the evaluation.
When working with an extended table, always consider the inheritance hierarchy rather than treating the table as an isolated object.
Wildcard ACLs Deserve Attention
ServiceNow also supports wildcard ACLs, which can apply broadly rather than targeting only one specific table or field.
A wildcard can therefore affect more resources than a developer initially realizes.
This is useful when a common security policy genuinely applies across a broad set of resources, but it can become dangerous when someone creates a broad rule simply because it is convenient.
A highly specific security requirement should generally not be implemented with an unnecessarily broad security rule.
If the requirement is:
Protect one field on one table.
a security rule covering a much larger set of resources introduces needless risk.
Broad ACLs should therefore be approached carefully, particularly in scoped application development where a developer may not immediately realize all of the resources affected by a generalized rule.
ACL Evaluation Can Involve More Than One Rule
Another important point is that ACL evaluation isn't simply a matter of finding one ACL record and asking whether it says "allow."
ServiceNow can have multiple applicable ACLs at different levels, and understanding how those rules interact is essential when troubleshooting access.
This is one reason an application can produce an apparently confusing result such as:
"I gave the user the role, but they still can't read the record."
The developer may have added a role to one ACL while another applicable rule still prevents the requested access.
Similarly, changing one ACL may not have the effect expected if another relevant security control is also part of the evaluation.
When troubleshooting security, don't ask only:
"Which ACL did I create?"
Ask:
"Which ACLs are applicable to this operation and resource, and what does the complete evaluation require?"
That shift in thinking is extremely useful.
Security Debugging Is a Skill of Its Own
When a user reports that they cannot access something, the first instinct should not necessarily be to modify the ACL.
Start by identifying exactly what is failing.
Can the user see the record?
Can they open it?
Can they read the field?
Can they modify the record?
Can they modify the field?
Can they create a new record?
Can they delete the record?
Different failures can point toward different access controls.
Then identify the user context.
Which roles does the user have?
Which groups are they in?
What relationship do they have to the record?
Is the user testing through the same interface and execution context that the intended users will use?
Only after establishing those facts should you start changing security configuration.
Otherwise, developers can easily "fix" an access problem by making permissions broader than they should be.
Security Can Be Correct Even When the Form Looks Broken
Sometimes a developer tests an application and finds that a field is unavailable or a button isn't present.
That may be intentional.
If the user does not have permission to perform an operation, the application may deliberately prevent that operation from appearing available.
The important distinction is whether the application is enforcing the intended rule or simply failing to render something because of a configuration problem.
This is why security testing should be performed with representative users rather than only with an administrator account.
An administrator may have broad access and therefore bypass the restrictions that ordinary users encounter. Testing exclusively as an administrator can hide security problems just as easily as it can hide usability problems.
Application Scope Adds Another Boundary
Scoped applications introduce another concept that CAD developers need to understand: application boundaries.
An application scope establishes a boundary around the application's components and affects how those components interact with resources belonging to other applications.
This is different from an ACL.
An ACL answers a question about whether access to a protected resource is authorized.
Application scope answers questions about application boundaries and whether one application is permitted to interact with resources owned by another application.
Those concepts can intersect, but they should not be treated as interchangeable.
For example, a developer may have permission to work with a table from the perspective of user authorization while the application itself still encounters a cross-scope restriction when attempting to interact with another application's resource.
The fact that the developer can open the record in the interface does not mean every application component automatically has unrestricted cross-scope access.
Cross-Scope Access Is an Architectural Concern
Imagine your custom application needs to call functionality provided by another scoped application.
The developer may be able to write the code and test it under conditions that make the operation appear to work, but the application still needs the appropriate cross-scope access configuration.
This is an important distinction because it is possible for the user's permissions and the application's permissions to represent different concerns.
The user might be authorized to perform an operation while the application component attempting to perform it is restricted by application scope.
Conversely, allowing a cross-scope application interaction does not automatically mean every user should be allowed to invoke that functionality.
When troubleshooting scoped application behavior, therefore, ask two separate questions:
Is the user authorized to do this?
and
Is this application component allowed to interact with that resource?
Those are not the same question.
Do Not Use Elevated Access as a Substitute for Design
When a developer encounters a security restriction during development, one tempting response is to find a way around it.
That can be useful for diagnosing the source of a problem, but it should not become the application's security architecture.
If the application requires a server-side process to perform an operation that ordinary users cannot perform directly, the design needs to deliberately account for that execution context and the security implications.
Simply bypassing the security model because "the script needs to do it" is dangerous.
The same principle applies to creating overly broad roles simply because they make development easier. A role that grants far more access than the business requirement needs may solve today's testing problem while creating tomorrow's security problem.
Security exceptions should be intentional, documented, and as narrow as practical.
Security Should Follow the Data Model
Security requirements can influence how an application should be designed.
Suppose a single record contains information that must be accessible to three different groups with completely different permissions. One group needs general request information, another needs internal processing details, and a third needs highly confidential information.
It may be possible to protect those fields individually, but the complexity of the security model should make you question whether the data belongs together in the first place.
Sometimes separating information into related records creates a cleaner security boundary.
This isn't a universal rule. There are legitimate reasons to keep related information together, and field-level security exists specifically because different fields can require different access.
The important architectural lesson is that security isn't merely something applied to a finished data model. The way you structure the data can make the security requirements easier or harder to express.
Security and Record Ownership
Ownership is another common source of contextual access requirements.
A business application might define access according to concepts such as:
-
The user who submitted the record
-
The user assigned to the record
-
The user's manager
-
The user's department
-
The user's group
-
A specific support or fulfillment group
-
A designated application role
These relationships often appear in business requirements without the word "security" ever being used.
For example:
A manager needs to review requests submitted by employees who report to that manager.
That's a security requirement even though the requirement sounds like a business process.
Likewise:
Agents can update cases assigned to their group.
Again, that is an authorization rule.
Learning to recognize the security implication hidden inside an ordinary business requirement is one of the most useful CAD skills you can develop.
A More Complete Example
Consider an application used to manage employee investigations.
Every employee can submit an investigation request. Once submitted, the employee can read the request but cannot modify it. Supervisors can read requests associated with their teams and can update certain operational fields. A specialized investigation group can work with the cases assigned to them. A confidential findings field should be visible only to members of a restricted role.
There is no single "investigation access" setting that solves this.
The application needs to establish:
Create access: employees need permission to create requests.
Read access: employees need to read records they are authorized to see.
Record-level restrictions: employees shouldn't automatically gain access to every investigation.
Write access: employees should lose the ability to modify submitted requests while authorized operational users retain appropriate write access.
Field-level restrictions: the confidential findings field needs additional protection.
Contextual access: supervisors and investigators may need access based on their relationship to the record.
Server-side enforcement: these rules must not depend solely on what the user sees on the form.
The application may also need appropriate roles, application scope considerations, and carefully designed server-side logic.
Notice how different the problem looks once you stop calling it simply "user permissions."
It's actually a collection of authorization decisions operating at different levels.
What CAD Questions Are Really Testing
When an application-development question gives you a security scenario, the correct answer is often hidden in the level of control being described.
If the question is about who should have access, think about roles and authorization.
If it is about what operation the user can perform, determine whether the requirement concerns create, read, write, or delete access.
If it is about which records a user can access, look for contextual or record-level security.
If it is about one particular field, consider field-level access.
If it says something should be hidden from the user interface, determine whether that is merely a usability requirement or whether the information actually needs to be protected.
If the scenario involves a scoped application interacting with another application, consider application boundaries and cross-scope access.
If the scenario suggests that the restriction must apply regardless of how the data is accessed, that is a strong indication that server-side enforcement is required.
The words in the scenario often tell you what layer you're supposed to be thinking about.
A Practical Security Checklist for Developers
Before considering an application's security complete, walk through the major operations rather than testing only the happy path.
For each important type of user, verify whether they can:
-
Create the records they are supposed to create.
-
Read only the records they are supposed to read.
-
Update records only when they are authorized to do so.
-
Delete records only when deletion is appropriate.
-
Read protected fields only when they are authorized.
-
Modify protected fields only when they are authorized.
-
Access related information appropriately.
-
Perform the intended actions through the user interface.
-
Attempt the same operations through other available interfaces where appropriate.
That last point is important because security testing should not stop at "the button disappeared."
The real test is whether the platform continues to enforce the rule when the operation is attempted outside the expected UI path.
The Difference Between Convenient Security and Correct Security
There are often several ways to make a particular user stop seeing something.
You can hide a field.
You can remove a button.
You can make a form read-only.
You can restrict a list.
You can filter what appears on a page.
Those techniques can all be useful.
But none should automatically be assumed to provide authorization.
Correct security asks whether the server will permit the operation.
Convenient UI behavior asks whether the user is presented with the option in the first place.
A well-built application usually does both. It prevents unauthorized operations at the server while also presenting an interface that doesn't constantly offer users actions they aren't allowed to perform.
The distinction matters because usability and security have different responsibilities.
The Mental Model That Makes ServiceNow Security Easier
When you're faced with a security requirement, reduce it to four questions:
Who is making the request?
Identify the user's roles, groups, and relevant relationships.
What are they trying to do?
Determine whether the operation is create, read, write, delete, or field access.
What are they trying to access?
Identify the table, record, field, or application resource involved.
What makes the decision contextual?
Determine whether access depends on ownership, assignment, department, group membership, another field value, or some other relationship between the user and the data.
From there, the appropriate mechanism becomes much easier to identify.
Roles help describe who is eligible.
ACLs enforce access.
Conditions and scripts can make authorization contextual.
Field ACLs provide more granular protection.
Client-side controls shape the user experience.
Application scope establishes application boundaries.
Those mechanisms work together, but they are solving different problems.
The Real Goal Is Not to Make the Application Inaccessible
Good application security isn't about making everything as restrictive as possible.
An application that nobody can use is technically secure in one very unhelpful sense.
The objective is appropriate access.
The employee should be able to perform the work they are responsible for. The manager should be able to see the information they need. The fulfillment team should be able to process its assigned work. Sensitive information should remain restricted to the people who genuinely require it.
Too little security exposes information or allows unauthorized changes.
Too much security prevents legitimate work and creates administrative overhead.
The developer's responsibility is to translate the business requirement into a security model that provides the appropriate boundary without creating unnecessary restrictions.
The CAD Takeaway
ServiceNow application security becomes much easier to reason about once you stop treating roles, ACLs, UI policies, client scripts, and application scope as interchangeable security features.
A role identifies a user's capabilities or membership in a security category, while an ACL provides the server-side authorization mechanism that determines whether a protected operation is permitted. ACLs can apply at different levels, including tables and fields, and access decisions can incorporate contextual information about both the user and the record. Client-side controls can make an interface behave appropriately, but they should not be relied upon to protect sensitive data or enforce authorization.
Scoped applications introduce another layer because application boundaries and user permissions are related but distinct concerns. A user may be authorized to perform an operation while an application component encounters a cross-scope restriction, just as an application may be permitted to interact with a resource without that automatically granting every user unrestricted access to it.
When a CAD scenario describes security, don't immediately look for the name of a configuration record you remember from a previous question. First identify who is acting, what operation they are attempting, what resource they are accessing, and what context determines whether that operation should be allowed.
Once those pieces are clear, the security mechanism usually becomes much easier to recognize.
And that is the important shift in thinking: you're not designing a collection of hidden fields and disabled buttons. You're designing an authorization model that must remain correct even when the application is used in ways you didn't anticipate.