Where Should the Logic Live? Understanding Client-Side and Server-Side Development in ServiceNow
One of the most important decisions a ServiceNow developer makes is also one of the easiest to get wrong: deciding where a piece of application logic should run.
A requirement might sound simple enough. A field needs to be populated automatically. A value should be validated. A user shouldn't be allowed to make a particular change. Something should happen when a record is saved. A button should perform an operation. The temptation is to find whichever scripting feature can make the requirement work and move on.
That approach can produce an application that appears to work perfectly while a user is sitting in front of the form. The trouble starts when the same record is modified through an import, an integration, a background process, a different interface, or another server-side process. Suddenly the rule that seemed reliable isn't being applied everywhere.
The underlying issue is usually that the developer solved a server-side problem with client-side logic, or treated a client-side user-experience requirement as though it needed server-side processing.
Understanding that boundary is one of the foundations of good ServiceNow development.
The Simplest Way to Think About the Boundary
The client is the user's browser. The server is the ServiceNow platform handling the request and the underlying data.
That sounds obvious, but it has significant consequences.
When a user opens a form and changes a field, ServiceNow can run client-side logic in the browser before anything is sent back to the platform. The form can react immediately, change what the user sees, populate values, display messages, or prevent an interaction from continuing.
Once the record is submitted, the request reaches the ServiceNow server. Server-side processing can then interact with the database, enforce business logic, evaluate security, update records, and perform operations that should not depend on the particular interface the user happens to be using.
The browser is therefore a good place to control the experience.
The server is where you generally need to control the application and its data.
That isn't an absolute rule for every situation, but it is an extremely useful starting point.
Client-Side Logic Has a Very Specific Advantage
Imagine an employee is completing an equipment request.
They select "Laptop" from an equipment type field. The form immediately reveals another field asking which operating system they need.
There is no reason to wait for the record to be saved for the interface to respond. The application already knows what the user selected, so client-side logic can react immediately.
This is the territory of things such as Client Scripts, UI Policies, and the client-side g_form API.
A UI Policy might make a field mandatory when certain conditions are met. A Client Script might perform more customized logic when a field changes or when a form loads. Both operate within the user's current form experience.
This can make an application feel considerably more intelligent.
The user selects something and the form responds.
The user clears a value and another field disappears.
The user enters information and the form provides immediate feedback.
These are good uses of client-side functionality because the requirement is fundamentally about what should happen while the user is interacting with the form.
But the Browser Isn't the Final Authority
Now change the scenario.
Suppose the organization has a rule that an equipment request must always have an assigned department before it can be processed.
You could make the Department field mandatory with a UI Policy.
That improves the form.
But does it guarantee that every equipment request in the system will have a department?
No.
An integration could create a request without ever displaying the form.
An import could update a record without going through the same client-side interaction.
A server-side script could modify the record.
A background process could perform an update.
None of those situations necessarily involve the browser running the UI Policy.
This is the distinction that causes so many problems for inexperienced developers:
A client-side restriction can control what happens in a particular interface. It does not automatically establish a universal rule for the data.
If the requirement is truly "this record must never be processed without a department," the enforcement mechanism needs to operate at the appropriate server-side level.
Think About What Happens Without a User
Here's a useful test whenever you're deciding where logic belongs:
Would this requirement still need to happen if nobody were looking at a form?
If the answer is yes, that should immediately make you think about server-side processing.
Suppose a new incident should automatically receive a particular assignment group based on its category.
An agent opening the incident isn't the important part of the requirement. The important part is what happens when the incident record is created or changed.
The incident might come from a user.
It might come from an integration.
It might be created by another ServiceNow application.
The business rule should still apply.
That's a strong indication that the logic belongs on the server rather than relying exclusively on something running in the browser.
This way of thinking is often more useful than trying to memorize a list of situations where one feature is "allowed" and another isn't.
Start with the requirement.
Then ask where that requirement needs to be enforced.
Business Rules Live on the Server
A Business Rule is one of the major server-side mechanisms in ServiceNow.
Business Rules can run when records are being inserted, updated, deleted, or queried, depending on how they are configured. They can inspect and manipulate records and perform server-side processing around database activity.
For example, suppose an application requires that when a request moves to an approved state, a particular field must be populated or another record must be created.
That is fundamentally different from changing the appearance of a form when a user selects a value.
The Business Rule is concerned with what happens to the record on the server.
This distinction becomes especially important when the same table is being accessed by many different processes. Server-side logic isn't tied to one particular form or interface.
That makes it appropriate for rules that need to remain true regardless of how the record reached the server.
"Before" and "After" Aren't Just Words
Business Rules can run at different points in the processing of a record, and understanding those timings matters.
A before Business Rule runs before the record is written to the database. This can be useful when you need to modify the current record before it is saved.
An after Business Rule runs after the record has been saved. This is useful when the record has successfully been committed and you need to perform related processing.
There are also async Business Rules, which allow processing to occur asynchronously rather than holding up the user's transaction.
The difference can matter enormously.
Imagine a request is being saved and you need to populate one of its fields before that record is written. A before rule may be appropriate.
Now imagine the record has been saved and the application needs to perform additional processing that doesn't need to keep the user waiting. An asynchronous rule may be a better fit.
The important point isn't simply knowing the names.
It's understanding that server-side logic has timing, and that timing is part of the application's behavior.
Don't Use a Business Rule Just Because You Can
There is another trap here.
Once developers learn Business Rules, it's easy to start putting everything into them.
That can create its own problems.
A requirement that exists only to change the appearance of a form doesn't belong in a Business Rule simply because Business Rules are powerful. The user needs immediate feedback, so client-side behavior is usually more appropriate.
Likewise, if the requirement describes a process that needs to coordinate several actions and is better represented as automation, a Business Rule may not be the clearest way to implement it.
ServiceNow gives developers several ways to accomplish things that appear similar from the outside.
The goal isn't to find the most powerful tool.
The goal is to use the mechanism whose responsibility matches the requirement.
GlideRecord Makes the Server Powerful
One reason server-side development is so important is that server-side code can work directly with ServiceNow's data through APIs such as GlideRecord.
Suppose an application needs to find all open fulfillment tasks associated with a particular request.
That isn't really a form problem.
It is a data problem.
Server-side code can query the appropriate table, retrieve matching records, inspect their values, and perform whatever processing the application requires.
This is one of the fundamental differences between the two environments.
Client-side code is primarily concerned with the user's current interaction.
Server-side code has access to the platform's data and processing environment.
That doesn't mean client-side code cannot retrieve information or communicate with the server. ServiceNow provides mechanisms for doing that. The important thing is recognizing that the client should not become a substitute for server-side application logic simply because it is convenient to write JavaScript there.
The Same Record Can Arrive Through Many Doors
Imagine a custom application with an Order table.
An order can be created through a custom form.
It can also be created through an integration.
A scheduled process can update it.
An administrator can modify it.
A Flow can change its state.
Another ServiceNow application can interact with it.
If an important business rule is implemented only through the custom form's Client Scripts, the application has effectively created different rules depending on how the record is accessed.
That's rarely what was intended.
The server provides a common point through which those different interactions can be processed.
This is why server-side enforcement is so important for data integrity. The application shouldn't have one set of rules when a person uses the form and a completely different set when an integration updates the same record.
A good application should behave predictably regardless of which legitimate path brought the data into the system.
Client Scripts and Business Rules Can Work Together
This isn't an either-or decision.
In many well-designed applications, the client and server perform complementary jobs.
Suppose a request requires an approval reason whenever its state changes to "Rejected."
The form can immediately tell the user that the approval reason is required. A UI Policy or Client Script can make the field mandatory and provide useful feedback before submission.
But the application may also need server-side enforcement so that a request cannot be stored in an invalid state if it is modified outside that form.
The client-side behavior gives the user a better experience.
The server-side behavior protects the application's data.
Those two layers are solving related problems from different perspectives.
This is a much better design than expecting one mechanism to handle everything.
Security Is Another Server-Side Concern
The distinction becomes even more important when security enters the picture.
Suppose a form hides a sensitive field from a particular group of users.
That's a user-interface decision.
It doesn't necessarily establish that those users are prohibited from accessing the underlying data.
Access Control Lists (ACLs) are part of ServiceNow's security model and determine whether users have the appropriate permissions to perform operations on secured resources.
This is why hiding a field, disabling a button, or making something read-only should not be confused with actual authorization.
A UI can make an option unavailable or invisible.
Security controls determine whether the operation is actually permitted.
For a developer, that distinction is critical. If the requirement says:
"Users in this role must not be able to modify this information."
the real requirement is about authorization, not simply about what the form should look like.
Where UI Actions Fit
The same reasoning applies to UI Actions.
A UI Action gives the user a way to deliberately initiate something. It might appear as a button, link, or menu item depending on how it is configured and where it is displayed.
Imagine an application has a "Close Request" button.
The button is part of the user interface.
But closing the request may involve server-side processing. The application might need to update the request, create another record, or perform additional validation.
The important distinction is between the trigger and the work.
The user clicking the button is a client-facing interaction.
What the application does as a result can involve server-side processing.
Thinking about the two separately makes it easier to design the application correctly.
What About GlideAjax?
Sometimes the browser needs information that only the server can provide.
For example, a user selects an employee and the application needs to retrieve information associated with that employee without submitting the entire form.
This is where GlideAjax can be useful.
GlideAjax allows client-side code to make a request to server-side code, commonly through a client-callable Script Include, and receive information back.
This creates a bridge between the two environments.
The important thing to understand is that GlideAjax doesn't turn server-side code into client-side code. The request crosses the boundary deliberately.
That distinction matters because developers should be conscious of when they are asking the server to perform work and when they are simply manipulating information already available to the browser.
A request to the server has a cost. Good applications don't make unnecessary server calls every time something happens on a form.
Script Includes Help Keep Server Logic Reusable
If several parts of an application need the same server-side functionality, putting all of that logic directly inside individual Business Rules or client-callable scripts can lead to duplication.
A Script Include provides a way to organize reusable server-side JavaScript.
For example, suppose an application needs to determine whether a particular employee is eligible for an equipment upgrade. That calculation might be needed by a Business Rule, a Flow-related process, and a client-side interaction.
Rather than implementing the calculation three different ways, the application can centralize the server-side logic and have the appropriate components call it.
This becomes increasingly valuable as an application grows.
The more places that contain copies of the same business logic, the more opportunities there are for those copies to diverge.
Centralizing reusable logic helps the application remain consistent and easier to maintain.
A Useful Question for Every Requirement
When you're given a development requirement, don't start by asking:
"Which ServiceNow feature do I use?"
Start with a different question:
"Who needs this behavior, and when does it need to happen?"
If the behavior exists to improve the user's interaction with a form, client-side functionality is a likely starting point.
If the behavior must protect the integrity of the data regardless of how the record is changed, think server-side.
If the user needs to deliberately initiate an operation, think about the interface mechanism that provides that action and then determine what processing belongs behind it.
If the client needs information that only the server can determine, consider an appropriate client-to-server mechanism.
If several parts of the application need the same server-side functionality, consider whether that logic belongs in a reusable Script Include.
The feature comes after the requirement.
A Scenario That Brings It Together
Imagine you've built a custom application for managing employee equipment.
An employee selects "Laptop" as the requested equipment type. The form immediately displays an Operating System field. That's a good client-side responsibility because the behavior is about the user's current interaction.
The employee submits the request. The application needs to ensure that every request has an employee and department before it is accepted. That's a server-side concern because the rule needs to remain true regardless of how the record is created.
The request is then moved into a fulfillment process. The application needs to create a fulfillment task when the request reaches the appropriate state. That is server-side application or automation behavior rather than simply a form-display requirement.
A fulfillment agent has a button that marks the request as completed. The button is the user-facing trigger, while the processing that validates and updates the request can occur on the server.
Finally, a user tries to access information they aren't authorized to see. The application cannot rely on hiding the information from the form. Security controls need to enforce the user's actual permissions.
From the employee's perspective, this all feels like one application.
From the developer's perspective, it is several layers working together.
That is exactly how you should think about ServiceNow development.
The Mistake Is Usually Not the Code
When an application behaves strangely, developers sometimes immediately start looking for a syntax error or a bad condition.
But a surprising number of problems aren't caused by incorrect JavaScript.
The logic is simply running in the wrong place.
A Client Script might be trying to enforce something that an integration can bypass.
A Business Rule might be doing work that should have been handled entirely in the user's browser.
A UI Action might perform an operation without the server-side validation required to keep the data consistent.
A developer might add several GlideAjax calls to compensate for information that could have been handled more efficiently.
These are architectural problems rather than syntax problems.
The code can be perfectly valid and the application can still be poorly designed.
The CIS-CAD Mental Model
When a CIS-CAD scenario asks you to choose between development mechanisms, it helps to stop thinking about the feature names for a moment.
Think about the boundary.
Is this about what the user sees or does on the form?
Think client.
Is this about what must happen to the data or application regardless of how the record is accessed?
Think server.
Does the user need to deliberately initiate an operation?
Think UI Action.
Does the browser need information that must be obtained from the server?
Think about a client-to-server mechanism such as GlideAjax.
Does multiple application logic need to reuse the same server-side functionality?
Think Script Include.
Does the requirement concern whether someone is actually permitted to access or modify something?
Think security and ACLs rather than simply changing the interface.
The exact implementation can become more complicated than this, but the mental model gives you somewhere sensible to start.
The Bigger Picture
ServiceNow applications are not really divided into "front end" and "back end" as cleanly as those terms might suggest in some other development environments. The platform provides many mechanisms that allow the two sides to interact, and a mature application often uses both.
The important thing is understanding their responsibilities.
The client should be responsible for creating a useful, responsive user experience. It can guide users, react to their actions, and provide immediate feedback.
The server should be responsible for processing the application's data and enforcing rules that need to remain true independently of a particular interface. It is also where the platform can perform operations against the database and apply server-side security and business logic.
The two sides work together, but they are not interchangeable.
That is the part worth remembering.
A form can tell a user that something isn't allowed. A server-side rule can make sure the application doesn't accept it anyway.
A button can give someone a convenient way to initiate an operation. Server-side logic can determine whether that operation is actually valid.
A Client Script can make a form feel intelligent. Server-side processing can make the underlying application reliable.
Once you understand that separation, ServiceNow scripting stops looking like a collection of competing features.
You start seeing the architecture underneath the application.
And that is the real skill behind choosing the right development mechanism: knowing where a requirement belongs before you decide how to implement it.