The Developer's Decision Tree: How to Solve a ServiceNow Requirement
One of the hardest parts of ServiceNow application development isn't learning what a Business Rule does, what an ACL does, or how a Client Script works. The difficult part comes when someone gives you a requirement that doesn't tell you which of those things to use.
Real requirements rarely arrive as clean platform questions.
Nobody walks into a development meeting and says, "I need a before Business Rule that performs a server-side calculation on the current record." They are more likely to say something like, "When an employee submits this request, populate the appropriate department information, don't let them change it, notify the fulfillment team, and make sure managers can approve it."
That is one requirement from the business perspective.
From the developer's perspective, it may contain several completely different problems.
The ability to solve those problems depends less on memorizing individual ServiceNow features and more on being able to decompose a requirement into its underlying behaviors. Who initiates the action? What has to happen immediately? What needs to be enforced on the server? What belongs to the user interface? Is the application responding to a record change, orchestrating a process, communicating with another system, or simply exposing reusable logic? Does the behavior need to work regardless of how the record is created? Does another application need to interact with the functionality?
Once those questions become habitual, the platform becomes much easier to navigate.
This is the skill that ties the rest of the CIS-CAD material together.
Start by Taking the Requirement Apart
Consider a requirement like this:
When an employee submits an equipment request, automatically determine the employee's department, prevent the employee from changing the department, create fulfillment work after approval, and notify the fulfillment team.
It would be a mistake to immediately ask, "Should I use a Business Rule or Flow?"
The requirement hasn't been decomposed enough to answer that question.
There are at least four distinct behaviors here:
-
Determine information from existing data.
-
Present that information appropriately to the user.
-
Prevent unauthorized modification.
-
Start downstream fulfillment after an approval event.
Those behaviors may belong to different parts of the platform.
The first question should therefore be:
What is the system actually being asked to do?
That sounds obvious, but it is one of the most important habits a developer can develop. Requirements frequently combine user-interface behavior, data manipulation, security, automation, and integration into a single sentence. If the entire sentence is treated as one technical problem, the resulting implementation often ends up with one script trying to do everything.
Good application design begins by separating those responsibilities.
Question One: Who or What Starts the Behavior?
The trigger is usually the best place to begin.
Ask what actually causes the requirement to occur.
Is a user changing a field?
Is a user clicking a button?
Is a record being inserted or updated?
Is another process reaching a particular state?
Is a scheduled time being reached?
Is another system sending data into ServiceNow?
Is ServiceNow supposed to initiate communication with an external system?
These are fundamentally different starting points.
Consider:
When the user changes the Requested for field, display the employee's department.
The trigger is a user interaction on a form.
Now consider:
Whenever an equipment request is created, store the employee's department on the record.
The trigger is the record operation.
Those requirements may appear nearly identical to a business user, but they have different technical implications.
The first is primarily about the user's experience while working with the form. The second describes behavior that must occur when the record is actually created.
That distinction becomes even more important when records can be created outside the form.
The Same Requirement Can Have Two Different Meanings
Suppose the requirement says:
Populate the manager when Requested for changes.
A Client Script may be appropriate if the purpose is to immediately display information while the user is filling out the form.
But now add:
The manager must always be correct, including when records are created by an integration.
The requirement has changed.
The browser is no longer the only environment that matters. The application needs server-side behavior because the rule must apply regardless of how the record enters the system.
This doesn't necessarily mean the Client Script should disappear.
The application might use client-side logic to provide immediate feedback and server-side logic to establish the authoritative value.
The important lesson is that the same business concept can require different implementations depending on where the requirement must hold true.
That is why asking "Which feature does this requirement use?" is often the wrong first question.
A better question is:
Under what circumstances must this behavior be true?
Question Two: Is This About the User Interface or the Data?
This is one of the most useful dividing lines in ServiceNow development.
Suppose a requirement says:
Make the justification field mandatory when the request type is Emergency.
That sounds like a form behavior.
If the purpose is to guide the user while entering information, a UI Policy or Client Script may be appropriate.
Now consider:
An Emergency request cannot be saved without a justification.
That is a stronger requirement.
The first statement describes what the user should experience.
The second describes a rule about valid data.
Those are related, but they are not necessarily the same implementation.
This distinction matters because client-side controls operate within a particular user interface. Server-side controls operate at the platform level.
If the organization is saying:
We don't want users to accidentally submit incomplete records.
client-side behavior may provide a good experience.
If the organization is saying:
The database must never contain a record that violates this requirement.
the developer needs to consider server-side enforcement.
The words used in the requirement often provide the clue.
Question Three: Is Someone Being Allowed to Do Something?
Security requirements can be hidden inside ordinary business language.
Consider:
Managers can approve requests, but employees cannot.
At first glance, this sounds like a button requirement.
You might create an Approve UI Action and make it visible only to managers.
That improves the interface, but it doesn't answer the actual security question.
The real requirement is:
Who is authorized to perform the approval operation?
Now the design needs to consider roles, ACLs, server-side authorization, and potentially the conditions under which a particular manager is allowed to approve a particular record.
The UI Action controls how the user initiates the operation.
The security model controls whether the operation is authorized.
That distinction should become automatic for a CAD developer.
Whenever a requirement contains words such as:
-
only
-
cannot
-
must not
-
authorized
-
allowed
-
their own
-
their group
-
their department
-
their manager
stop and consider whether the requirement is actually describing an authorization rule.
A Button Is Not a Permission
Imagine a request form contains an Approve button.
The developer configures the UI Action so that only users with the manager role can see it.
That is useful because employees don't need to be presented with an action they cannot perform.
But suppose someone invokes the underlying operation through another path.
If the server-side implementation simply assumes that anyone who reaches the operation must be authorized because the button was hidden, the application has confused interface configuration with security.
A better design separates the responsibilities.
The UI Action determines whether the action is presented.
The server-side security model determines whether the user is authorized.
The processing logic performs the approved operation.
If approval also needs to create fulfillment work, that downstream behavior belongs to the appropriate automation mechanism rather than being mixed indiscriminately into the interface definition.
One requirement has now become several coordinated responsibilities.
That is normal.
Question Four: Is the User Initiating an Action, or Is the System Reacting to an Event?
This distinction becomes particularly useful when choosing between UI Actions and automated server-side mechanisms.
Consider:
When the user clicks "Close Request," set the request to Closed.
That is an explicit user action.
A UI Action is a natural place to represent that action, with appropriate server-side validation and processing.
Now change the requirement:
Whenever a request enters the Closed state, perform cleanup processing.
The trigger is no longer a button click.
The application is reacting to a state change.
A Business Rule or another appropriate automation mechanism may therefore be more suitable.
The distinction matters because tying the cleanup behavior to the UI Action would mean the behavior depends on that particular path being used. If another process changes the request to Closed, the cleanup may never happen.
This is a recurring design principle:
Attach behavior to the event that actually defines the requirement, not merely to one interface through which the event currently happens.
Question Five: Is This a Single Operation or a Business Process?
This is where developers can easily overuse Business Rules.
Suppose the requirement says:
When an equipment request is approved, create a fulfillment task, assign it to the appropriate group, send a notification, wait for fulfillment, and update the request when the task is complete.
That is not simply "something that happens when a record changes."
It is a process.
There is a trigger, multiple actions, branching possibilities, potentially asynchronous work, and a relationship between stages of the process.
This is exactly the kind of situation where a process-oriented automation mechanism such as Flow Designer may be a better representation than embedding the entire process inside a Business Rule.
The Business Rule isn't inherently wrong because it can technically perform many of those operations. The problem is architectural.
A developer should ask:
Will another developer be able to understand the business process by looking at how it is implemented?
If the answer is yes, the design is probably moving in the right direction.
If understanding the process requires opening several scripts and mentally reconstructing the sequence of side effects, the implementation may be putting too much responsibility into low-level scripting.
One Trigger Does Not Mean One Mechanism
This is an important concept because developers sometimes assume that a requirement should map to exactly one ServiceNow feature.
It doesn't have to.
Take this requirement:
When an employee submits a request, immediately show the employee's manager, prevent the employee from changing it, validate the value on the server, and after approval create a fulfillment task.
A reasonable architecture could involve several components.
The form might use client-side behavior to display the manager immediately.
The application's security model might determine who is allowed to modify the field.
Server-side logic might establish or validate the authoritative value.
A Flow might handle the approval and fulfillment process.
A reusable Script Include might contain the logic for determining the appropriate fulfillment group if multiple parts of the application need the same calculation.
There is nothing inherently wrong with having several mechanisms involved.
The problem is having several mechanisms involved without clear responsibilities.
Question Six: Does the Logic Need to Be Reused?
Now imagine that three different parts of the application need to determine an employee's eligibility for a particular equipment request.
One developer could copy the calculation into three scripts.
It may work perfectly today.
It also means there are now three versions of the same business logic.
What happens when the eligibility rules change?
Someone has to remember all three locations.
This is where reusable server-side logic becomes important.
A Script Include can provide a central implementation that other server-side components can call.
The trigger doesn't necessarily belong in the Script Include.
The Script Include isn't necessarily responsible for deciding when the calculation occurs.
Its job is to provide reusable functionality.
This distinction is one of the simplest ways to prevent ServiceNow scripting from becoming a collection of duplicated code.
A useful question is:
Am I deciding when something happens, or am I providing reusable logic that something else can call?
Those are different responsibilities.
Question Seven: Does the Browser Need Server-Side Information?
Sometimes the user interface needs information that is not already available on the form.
Suppose the user selects an employee and the application needs to retrieve information from the server to update the form.
That is where the client/server boundary becomes important.
The browser can respond to the user's interaction, but it may need to request information from server-side logic.
A common pattern is:
Client Script → GlideAjax → Script Include → server-side processing → response → Client Script
The important part isn't memorizing that sequence as a recipe.
The important part is understanding why it exists.
The client knows about the user's interaction.
The server knows about server-side data and logic.
GlideAjax provides a controlled way for client-side code to request server-side functionality.
This is another example of why understanding execution context matters more than memorizing APIs in isolation.
Question Eight: Is the Requirement About the Current Record or Another Record?
This question can completely change the design.
Suppose a request needs a calculated value before it is saved.
A before Business Rule may be appropriate because the current record can be modified as part of the save operation.
Now suppose the requirement says:
Whenever a request is approved, create a separate fulfillment task.
The application is no longer simply changing the current record.
It is producing another record as a consequence.
That introduces additional considerations:
-
Should the new record be created synchronously?
-
Does the user need to wait?
-
Could creating the record trigger additional automation?
-
What happens if the related operation fails?
-
Does the process belong in a Flow?
-
Is reusable logic involved?
-
Could the design create recursion or unintended side effects?
The distinction between changing the current record and causing other records to change is extremely useful when evaluating Business Rules and other automation.
Question Nine: Does the Work Need to Happen Immediately?
Timing is an architectural decision.
Suppose a user saves a record and the system needs to calculate a value that must be present when the record is stored.
That work belongs in the transaction.
Now suppose the system needs to generate a report, contact another system, or perform a lengthy operation that doesn't need to delay the user's save.
Making the user wait for unrelated work may be unnecessary.
The developer should therefore ask:
Does the initiating transaction actually need the result?
If the answer is no, asynchronous processing may be appropriate.
This is why "after" and "async" are not merely variations of the same Business Rule. They represent different timing expectations.
The more expensive the work becomes, the more important that distinction is.
Question Ten: Does the Requirement Cross the ServiceNow Boundary?
Consider a new requirement:
When an approved equipment request is ready for fulfillment, send the request information to an external inventory system.
Now the application has crossed another architectural boundary.
The developer needs to determine whether the interaction is inbound or outbound, what interface the external system provides, how authentication works, what data needs to be exchanged, and what should happen if the external system is unavailable.
If ServiceNow is sending a request to an external REST endpoint, the solution may involve a REST integration.
If an external system is sending data into ServiceNow, an inbound integration pattern may be more appropriate.
If large amounts of external data need to be brought into ServiceNow and transformed into internal records, Import Sets and Transform Maps may be more appropriate.
Again, the question isn't:
"Do I know what REST is?"
The more useful question is:
What kind of data movement is the requirement describing?
REST and Import Sets Solve Different Problems
Imagine an external inventory system sends a daily file containing thousands of device records.
That scenario has a very different shape from:
Whenever a device is assigned in ServiceNow, call the inventory system's API and immediately retrieve its current status.
Both involve external data.
The first sounds like a data-loading and transformation problem.
The second sounds like an API interaction that needs to happen in response to an application event.
Choosing between integration mechanisms becomes much easier once the underlying requirement is understood.
The technology should follow the data flow.
Question Eleven: What Happens When the Application Leaves Development?
A requirement isn't necessarily complete just because the code works.
Suppose you've created a scoped application containing tables, scripts, roles, flows, and other application files.
Now someone asks:
How do we move this to the test instance?
That's a different problem from writing the original functionality.
The developer now needs to think about application packaging, source control, Update Sets, the Application Repository, dependencies, versions, installation, upgrades, and the target environment.
The correct mechanism depends on what is actually being moved and how the application is being managed.
This is why application management belongs in the development conversation.
An application is not finished when the developer sees a green test result in a development instance.
It has to survive the rest of its lifecycle.
A Requirement Can Change While You Are Solving It
One of the most important habits to develop is recognizing when additional requirements change the architecture.
Consider this initial requirement:
Populate the employee's department when Requested for changes.
A developer might reasonably start with client-side behavior.
Then the business adds:
The department must also be populated when records are created through integrations.
Now server-side processing matters.
Then they add:
Employees must not be able to change the department.
Now security matters.
Then:
Managers can override the department for their own teams.
Now the authorization requirement becomes contextual.
Then:
Every approved request must create fulfillment work.
Now automation enters the picture.
Then:
The fulfillment system is external.
Now integration enters the picture.
The requirement began as something that sounded like a simple form behavior.
By the time the requirements are complete, it touches UI behavior, server-side processing, authorization, automation, and external data.
This is why experienced developers don't immediately lock themselves into an implementation based on the first sentence they hear.
They first try to understand the complete behavior.
The Architecture Should Follow the Requirement
There is a natural temptation in any platform to build around the tools you know best.
A developer who is comfortable with Business Rules may put everything into Business Rules.
A developer who prefers Flow Designer may try to build everything as a Flow.
A developer who enjoys client scripting may solve interface problems with Client Scripts even when the underlying requirement belongs on the server.
That is backwards.
The application should not be designed around the developer's favorite feature.
The implementation should be selected based on the requirement.
A useful decision process looks something like this:
What caused this behavior?
Identify the trigger.
Where does the behavior need to be true?
Determine whether the requirement is about the UI, the server, the data, security, or an external system.
When must it happen?
Determine whether it must occur immediately, as part of the transaction, afterward, asynchronously, or on a schedule.
Who is allowed to do it?
Identify whether authorization or contextual security is involved.
What data does it affect?
Determine whether the current record, related records, fields, or external systems are involved.
Does the logic need to be reused?
If so, separate reusable logic from the mechanism that triggers it.
Is this a process?
If the requirement contains multiple stages, approvals, waits, branches, or downstream actions, consider process-oriented automation.
That sequence can eliminate a surprising number of bad implementation choices before any code is written.
A Full Scenario: Putting the Pieces Together
Consider a custom application that manages employee equipment requests.
The business provides this requirement:
Employees can submit equipment requests. The system should determine the employee's department automatically. Employees should see the department while completing the form but should not be able to change it. Managers can approve requests for employees on their teams. Once approved, a fulfillment task should be created and assigned to the correct fulfillment group. The fulfillment system should receive the request information through an external API. When fulfillment is complete, the request should be updated.
At first glance, this sounds like one feature.
It isn't.
Let's decompose it.
The employee selects a requester
The interface needs to respond immediately.
That suggests client-side behavior if the purpose is to provide immediate feedback.
The department must be authoritative
The department cannot depend exclusively on what happened in the browser.
Server-side logic should establish or validate the value when the record is processed.
The employee cannot change the department
That is an authorization concern if the restriction is meant to be enforced rather than merely presented as read-only.
The UI can make the field unavailable to the employee, but server-side security must establish the actual boundary.
A manager can approve requests for their team
This is not simply "manager role = access."
The relationship between the manager and the employee may matter.
That introduces contextual authorization.
Approval creates fulfillment work
This is a downstream process triggered by a business event.
The developer should consider whether Flow Designer or another automation mechanism provides a clearer representation than putting the entire process into a Business Rule.
The fulfillment system is external
Now the application needs an integration.
The developer must determine the appropriate API mechanism, authentication, request structure, response handling, and failure behavior.
Completion updates the original request
Now the application needs to handle the result of the fulfillment process and update the appropriate ServiceNow record.
What initially looked like one requirement has become a collection of related architectural decisions.
That is normal.
The goal isn't to force all of these behaviors into one mechanism. The goal is to make each responsibility clear.
The Wrong Way to Solve the Scenario
A developer could technically attempt to solve much of this with a single collection of scripts.
A Client Script could populate the department.
Another Client Script could make it read-only.
A UI Action could approve the request.
A Business Rule could create the fulfillment task.
That Business Rule could call an external API.
Another Business Rule could detect completion.
Additional scripts could enforce some of the same restrictions.
The application might even appear to work.
The problem is that the architecture is now organized around individual moments of implementation rather than around clear responsibilities.
What happens when an integration creates the request?
What happens when someone updates the department through another interface?
What happens if the approval operation is attempted without using the button?
What happens if the external system is unavailable?
What happens if another developer needs the same employee eligibility calculation?
What happens if the fulfillment process becomes more complicated?
The application has accumulated behavior without establishing clear ownership of that behavior.
That is exactly the kind of design that becomes painful later.
The Better Way to Think About It
A better design starts by assigning responsibility.
The user interface handles immediate interaction.
Server-side logic establishes authoritative data.
Security controls authorization.
A UI Action represents an explicit user-initiated operation.
Automation handles the downstream process.
Reusable server-side components contain shared logic.
Integration mechanisms handle communication with external systems.
Application management mechanisms handle the lifecycle of the resulting application.
The exact implementation will vary depending on the application's requirements, but the reasoning process remains consistent.
The developer isn't asking:
"Which ServiceNow feature can do all of this?"
The developer is asking:
"What are the distinct responsibilities inside this requirement, and what part of the platform should own each one?"
That is a much stronger question.
When the Obvious Answer Is Probably Wrong
CAD scenarios often become easier when you recognize the tempting answer that doesn't quite fit.
If the requirement says "make the field read-only", don't automatically assume security is involved. It may simply be a user-interface requirement.
If it says "users must not be able to modify the field", now you should think about server-side enforcement.
If it says "when the user clicks a button", don't automatically reach for a Business Rule. The requirement may describe an explicit UI action.
If it says "whenever the record enters this state", don't automatically tie the behavior to a button. The state transition may occur through several paths.
If it says "perform several steps, wait for an approval, then continue", don't automatically create a large Business Rule. The requirement may describe a process.
If it says "the same logic is needed in several places", don't copy the script. Consider reusable server-side logic.
If it says "must also work when records are created by integrations", don't rely exclusively on client-side behavior.
If it says "send this information to another system", don't treat the requirement as ordinary record automation. There is an integration boundary to design.
If it says "move this application to another instance", don't confuse application lifecycle management with simply moving a few development changes.
These distinctions are more valuable than memorizing isolated answers because they give you a way to reason through unfamiliar scenarios.
What to Do When Two Solutions Both Work
This is one of the more realistic problems a developer encounters.
Sometimes two different ServiceNow mechanisms can technically satisfy a requirement.
A Business Rule and a Flow might both be able to react to the same record change.
A Client Script and a UI Policy might both be able to influence the form.
A Script Include might be callable from several places, while a small piece of logic could simply be written locally.
The question then becomes:
Which solution expresses the requirement most appropriately?
Consider maintainability.
Consider execution timing.
Consider reuse.
Consider scope.
Consider security.
Consider whether another developer can understand the implementation.
Consider whether the behavior is tied too tightly to one interface.
Consider what happens when the requirement changes.
The fact that something can be implemented in a particular mechanism does not mean it should be.
Good ServiceNow development is often less about discovering whether something is possible and more about deciding which possible implementation creates the cleanest application.
Don't Solve Tomorrow's Requirement Today
There is also a danger in overengineering.
Once developers learn all of these mechanisms, it can become tempting to introduce abstractions everywhere.
A simple requirement doesn't necessarily need a complicated architecture.
If a field needs to be populated on the current record before it is saved, a straightforward before Business Rule may be exactly what is needed.
If a simple form behavior can be expressed cleanly with a UI Policy, there may be no reason to create a large Client Script.
If a small process can be represented clearly with a simple Flow, there may be no benefit in introducing multiple custom Script Includes and events.
The goal is not maximum architectural complexity.
The goal is appropriate complexity.
A good developer knows when to separate responsibilities and when separation would simply make a simple requirement harder to understand.
A Useful Mental Model for CAD Questions
When facing an unfamiliar scenario, you can reduce the problem to a sequence of decisions.
Start with the trigger
What caused the behavior?
User interaction, record operation, process state, schedule, or external system?
Identify the execution context
Does the behavior belong in the browser, on the server, or across both?
Identify the authorization boundary
Is the requirement describing something users should see, or something users are actually permitted to do?
Identify the data boundary
Is the application changing the current record, another record, or an external system?
Identify the timing
Must the operation happen before the transaction completes, after it completes, asynchronously, or at a scheduled time?
Identify reuse
Does the logic belong to one implementation, or does it represent functionality that multiple components should call?
Identify process complexity
Is this one operation, or is it a multi-step business process with approvals, branches, waits, and downstream consequences?
Identify the lifecycle
Does the solution need to be packaged, versioned, deployed, upgraded, or shared with another application?
Once those questions are answered, the list of reasonable implementation choices becomes considerably smaller.
The Developer's Decision Tree
A simplified decision tree might look like this:
Something needs to happen.
→ What caused it?
A user is interacting with a form
→ Think about client-side behavior and UI configuration.
A user explicitly initiated an operation
→ Consider a UI Action and the server-side processing behind it.
A record was inserted, updated, deleted, or queried
→ Consider server-side record processing such as Business Rules.
A multi-step business process needs to run
→ Consider Flow Designer or another appropriate process mechanism.
The work needs to happen later or without delaying the transaction
→ Consider asynchronous processing.
The same server-side behavior is needed in multiple places
→ Consider a Script Include or other reusable component.
The user interface needs server-side information
→ Consider a client/server pattern such as GlideAjax with a Script Include.
The requirement determines who may perform an operation
→ Think about roles, ACLs, and server-side authorization.
The requirement involves another system
→ Identify the appropriate integration pattern.
The requirement concerns moving or maintaining the application
→ Consider application lifecycle and deployment mechanisms.
This isn't a list of absolute rules.
It is a way of narrowing the problem.
The Most Important Question Is Often the One You Ask Before Writing Anything
Experienced developers often appear to move quickly because they recognize patterns.
They hear:
"When this field changes..."
and immediately know to investigate the client-side requirement.
They hear:
"Users in this group can update only their assigned records..."
and immediately recognize a security problem.
They hear:
"After approval, create these records, wait for fulfillment, and notify..."
and recognize a process.
They hear:
"Send this data to our external system..."
and recognize an integration boundary.
That speed doesn't come from memorizing more ServiceNow features.
It comes from knowing what questions to ask.
The strongest CAD developers aren't necessarily the people who can name the most APIs from memory. They are the people who can look at an ambiguous requirement and identify the underlying technical problems before choosing an implementation.
Building for the Requirement You Have, Not the Tool You Know
ServiceNow provides a large collection of mechanisms because applications have different kinds of behavior.
Client-side scripting exists because users interact with applications.
Server-side scripting exists because the platform needs to process and enforce data.
ACLs exist because authorization needs a reliable boundary.
UI Actions exist because users sometimes deliberately initiate operations.
Business Rules exist because record activity can require server-side behavior.
Flows exist because business processes need orchestration.
Script Includes exist because logic needs to be reused.
Integration capabilities exist because applications rarely exist in complete isolation.
Application management capabilities exist because software has a lifecycle beyond development.
None of these mechanisms is inherently the "best" one.
The best choice depends on what the requirement actually says.
That is the central idea behind the entire CIS-CAD development model.
The Capstone Lesson
By this point in the series, you have seen the individual pieces of ServiceNow application development from several different directions.
You've looked at what makes up an application and how those components fit together. You've followed the path of a user's interaction with the interface. You've examined the boundary between client-side and server-side behavior. You've looked at how authorization differs from simply hiding something in the UI. You've considered how Business Rules, Flow Designer, events, and reusable scripting fit into automation. You've looked at how ServiceNow communicates with external systems and what happens to an application after it leaves development.
The purpose of learning all of those things separately isn't to create a larger vocabulary list.
It is to give you enough understanding to make decisions.
When someone gives you a requirement, don't begin by searching your memory for the ServiceNow feature whose name sounds closest to the requirement.
Break the requirement apart.
Find the trigger.
Determine the execution context.
Identify the data being affected.
Determine whether authorization is involved.
Consider timing.
Look for reusable logic.
Decide whether you're dealing with a single operation or a larger process.
Identify whether another system is involved.
Then consider how the application will eventually be managed and deployed.
The answer may involve one ServiceNow feature.
More often, it will involve several.
What matters is that each piece has a reason for being there.
That is the difference between knowing ServiceNow development features and actually understanding ServiceNow application development.
The goal isn't to make the platform do something.
The goal is to understand what the requirement really means, where that behavior belongs, and why that design will continue to make sense after someone changes the requirement six months from now.
And that is ultimately what the CIS-CAD exam is asking you to demonstrate: not simply whether you recognize individual platform features, but whether you can reason from a development requirement to an appropriate ServiceNow solution.