Certified Application Developer (CAD)
SERVICENOW · CAD · Certification Hub
| Questions | 60 |
| Passing Score | 70% |
| Question Types | Multiple choice (one answer), Multiple choice (multiple answers) |
Certification Summary
The ServiceNow Certified Application Developer exam is for technical consultants and platform developers who build custom scoped applications. It targets the people tasked with extending the platform because a department head insists on a custom workflow, forcing the developer to manage the resulting technical debt before the next platform upgrade hits.
The exam focuses heavily on Application User Interface, Designing and Creating an Application, Security and Restricting Access, and Application Automation, which collectively make up the majority of the content. You will also encounter questions regarding Working with External Data and Managing Applications. You will be tested on the correct syntax for GlideRecord queries and the specific implications of cross-scope access privileges within the Now Platform.
Official blueprint weighting
Domain details and study notes
Domain 1: Designing and Creating an Application — 20%
A clean application starts long before anyone adds fields to a form.
You’ll need to understand application scope, tables, data models, application files, roles, and the difference between extending an existing table and creating a new one. Poor data design creates duplicate information, awkward references, brittle scripts, and maintenance problems that follow the application into production. Study how Studio and App Engine Studio organize development work, how records relate, and when configuration belongs inside the application scope. Don’t design only for the first request. Consider ownership, reuse, deployment, upgrades, and long-term support. The strongest applications begin with a clear data model and a well-defined boundary.
Domain 2: Application User Interface — 20%
The user interface domain covers the tools used to shape how people view, enter, and interact with application data.
You’ll need to understand forms, lists, views, UI policies, client scripts, UI actions, modules, workspaces, and related interface components. Pay close attention to execution context. A requirement may sound simple, but the correct solution depends on whether the behavior is client-side, server-side, role-specific, form-specific, or reusable across interfaces. Hiding a field, making it mandatory, changing its value, or enforcing access all require different approaches. Practice selecting the least complex tool that meets the requirement. A clear interface should guide users without introducing unnecessary scripting or inconsistent behavior.
Domain 3: Security and Restricting Access — 20%
Application security requires a deliberate access model rather than scattered checks added after development.
You’ll need to understand roles, users, groups, access control rules, table access, record access, field access, scripted conditions, application scope, and cross-scope privileges. Don’t assume that hiding a field on a form protects its data. Presentation controls affect what users see in one interface, while ACLs determine whether they can access the information at all. Study how multiple access rules combine and how inherited roles or table hierarchies affect the final result. A maintainable design grants the minimum required access through clear, testable rules that align with actual business responsibilities.
Domain 4: Application Automation — 20%
Application automation is about choosing the right execution method for the requirement.
You’ll need to understand Flow Designer, business rules, script includes, scheduled logic, events, notifications, and other automation components. Focus on when each mechanism runs, what data it can access, and whether the logic should be reusable. Record-triggered behavior needs clear conditions and predictable timing, while shared server logic should be placed in callable components rather than copied across scripts. Watch for recursion, duplicate actions, and hidden dependencies. The best solution usually minimizes custom code while keeping the behavior supportable and visible. Test failure conditions and negative paths, not just the successful outcome.
Domain 5: Working with External Data — 10%
External data introduces unreliable networks, mismatched schemas, changing payloads, and systems your application doesn’t control.
You’ll need to understand data sources, import sets, transform maps, coalescing, REST integrations, web services, authentication, and scheduled imports. Stage and validate incoming data before moving it into production tables. A successful transform doesn’t guarantee clean results if coalescing, field mappings, or identifiers are wrong. Study the difference between importing data, exposing data to another system, and invoking an external service. Common failures include duplicate records, expired credentials, unexpected null values, and payload changes. Strong integrations make errors visible, preserve traceability, and support safe recovery.
Domain 6: Managing Applications — 10%
Managing applications covers how development work is versioned, moved, reviewed, and maintained across environments.
You’ll need to understand application repositories, update sets, source control, delegated development, application publishing, and deployment methods. These tools don’t capture or move the same things, so know what each one is designed to manage. Pay attention to application scope, dependencies, collisions, missing records, and version differences. A disciplined lifecycle includes development, review, testing, versioning, deployment, validation, and rollback planning. Don’t assume every configuration change travels automatically. Production fixes should also be reconciled with the authoritative development source so later releases don’t overwrite or lose them.
Where you stand
Based on your timed exam results, study progress, confidence ratings, and Proof write-ups on official domains for this certification. Flashcards and labs are counted for the cert as a whole. Articles, cheat sheets, and case files do not change these standings.
Log in to fill this chart from your exam, study, and Proof history.
| Domain | Exam | Study | Calibration | Proof |
|---|---|---|---|---|
| Application User Interface20% of exam | — | None | — | None |
| Designing and Creating an Application20% of exam | — | None | — | None |
| Security and Restricting Access20% of exam | — | None | — | None |
| Application Automation20% of exam | — | None | — | None |
| Working with External Data10% of exam | — | None | — | None |
| Managing Applications10% of exam | — | None | — | None |
Resource Center
Complete the check below to request missing content.
The final CIS-CAD Breakdown brings the concepts from the entire series together around the skill that matters most in real ServiceNow development: taking a business requirement and determining how it should actually be implemented. Instead of introducing another isolated platform feature, this article focuses on the reasoning process developers use to break complicated requirements into smaller technical responsibilities and determine where each piece belongs. The Breakdown walks through the questions that should be asked before writing code or configuring a solution. What triggers the behavior? Does it belong on the client, the server, or both? Is the requirement about the user interface, data, authorization, automation, or an external system? Does timing matter? Does the logic need to be reusable? Is the requirement describing a single operation or an entire business process? How might the solution behave when records are created through another interface or when the application moves beyond the development environment? Through practical scenarios, the article demonstrates how a single business requirement can involve several ServiceNow mechanisms without turning into an unnecessarily complicated implementation. Client-side behavior, server-side logic, UI Actions, Business Rules, Flow Designer, Script Includes, ACLs, integrations, and application management are considered as parts of a larger development architecture rather than as disconnected features to memorize. For CIS-CAD preparation, the goal is to develop the ability to recognize the clues hidden inside a scenario and use them to narrow down the appropriate solution. The capstone reinforces the distinction between what a feature *can* do and what it is *appropriate* to use for, helping readers approach unfamiliar certification questions with the same reasoning process they would use when designing an actual ServiceNow application.
Building a ServiceNow application that works in development is only the beginning. This Breakdown examines what happens after the application has been created and needs to be tracked, tested, distributed, installed, maintained, and eventually upgraded. It explains why application development needs to be treated as a lifecycle rather than a collection of changes made inside a single instance. The article explores the role of application files, Update Sets, source control, the Application Repository, application versions, dependencies, application scope, and the differences between installing and upgrading an application. Rather than presenting these as unrelated platform features, it explains how they fit together and why each exists within the broader development and deployment process. Particular attention is given to the distinctions that can be easy to blur when preparing for the CIS-CAD exam. Update Sets and source control serve different purposes, application distribution is different from tracking development changes, and installing an application into a new environment is not the same situation as upgrading an application that is already installed. Dependencies and cross-scope relationships can also affect whether an application can operate as expected outside the environment where it was developed. For CIS-CAD preparation, the goal is to develop a practical understanding of how ServiceNow applications are managed throughout their lifecycle. By the end, readers should be better equipped to reason through deployment and application-management scenarios, recognize which mechanism addresses a particular problem, and understand why good application development includes planning for the application's future rather than stopping when the first version works.
This Breakdown explores what happens when a ServiceNow application needs to exchange information with systems outside the platform. Rather than treating REST, SOAP, Import Sets, Transform Maps, and other integration tools as isolated pieces of terminology, it explains how to think about external data as an end-to-end process: where the data originates, how it enters or leaves ServiceNow, how it is authenticated and transported, and what happens after ServiceNow receives it. The article examines the major approaches developers can use when working with external systems, including inbound and outbound integrations, REST APIs, SOAP web services, REST Messages, Scripted REST APIs, Data Sources, Import Sets, and Transform Maps. It focuses on the architectural differences between these mechanisms and the kinds of requirements that make one approach more appropriate than another. Particular attention is given to an important CAD skill: choosing an integration mechanism based on the actual requirement rather than simply recognizing the name of a technology. The Breakdown considers scenarios such as retrieving information from an external system, exposing ServiceNow data to another application, importing larger amounts of structured data, transforming external information into ServiceNow records, and determining where authentication and processing belong. For CIS-CAD preparation, the goal is to move beyond memorizing definitions and develop a practical mental model for integration design. By the end, readers should be better equipped to look at an external-data scenario, identify the direction and nature of the data exchange, understand the role of the available ServiceNow integration components, and reason through which approach best fits the requirement.
ServiceNow application security is much more than assigning roles and hiding fields on a form. This breakdown takes a closer look at what actually happens when ServiceNow decides whether a user can read, create, update, or delete data, and how roles, ACLs, conditions, scripts, field-level security, and application scope fit together. It also explains why client-side controls such as UI Policies, Client Scripts, and UI Actions should not be mistaken for the security boundary that protects the underlying data. The article digs into the areas that can make application security confusing in real implementations, including contextual access based on the current user and record, inherited and wildcard ACLs, multiple applicable access controls, cross-scope restrictions, and the difference between user authorization and application-to-application access. Rather than treating these as isolated configuration features, it shows how to reason through a security requirement from the operation being requested to the resource being protected and the context that determines whether access should be allowed. For the ServiceNow CAD exam, the goal is to develop the ability to recognize which security mechanism belongs to a particular problem rather than simply memorizing terminology. The result is a more practical understanding of how to design, troubleshoot, and test security in a custom ServiceNow application without relying on interface-level restrictions as a substitute for actual authorization.
ServiceNow gives developers several ways to automate behavior, but knowing that a Business Rule, Flow, Script Include, Event, or scheduled process can accomplish something is very different from knowing which one belongs in a particular design. The wrong choice can create unnecessary complexity, slow down transactions, introduce unexpected side effects, or make an application difficult for the next developer to understand. This Breakdown examines how to think about automation as an application-design problem rather than a collection of individual ServiceNow features. It looks at the differences between record-triggered logic, business processes, reusable server-side code, asynchronous processing, events, client-side behavior, and scheduled work, with particular attention to the clues that should influence the architectural decision. The focus is not on memorizing which tool goes with which requirement. Instead, the article develops a practical way to recognize what kind of behavior a requirement is actually describing, where that behavior belongs, and how seemingly small automation decisions can affect the reliability and maintainability of a ServiceNow application.
ServiceNow gives developers a surprisingly large number of ways to make an application behave differently, and several of them can appear to solve the same problem. The difficult part isn't learning that Client Scripts, UI Policies, Business Rules, Script Includes, UI Actions, GlideAjax, and ACLs exist. It's understanding why one belongs in a particular situation while another could create problems. This Breakdown explores the boundary between the browser and the ServiceNow server and shows how that boundary should influence development decisions. It looks at what client-side logic is actually responsible for, when server-side processing is necessary, how user-interface behavior differs from true data enforcement, and how the two sides can work together. The goal is to develop the kind of reasoning that helps when building a real application: start with what the requirement needs to accomplish, determine where that behavior needs to occur, and only then choose the ServiceNow mechanism that belongs there. That way, developers aren't simply making something work on a form—they're building behavior that continues to make sense when the application is used through other paths as well.
Building a ServiceNow application is about much more than creating tables, fields, and forms that satisfy today's requirements. The choices made around the data model, table structure, references, inheritance, and relationships determine how easily that application can be automated, secured, integrated, reported on, and changed as the business evolves. This Breakdown looks at the architectural decisions that sit underneath a ServiceNow application. It explores when to use existing platform tables, when a custom table makes sense, how table extension should be approached, why reference fields are more than a convenient form control, and how seemingly small choices around data duplication and field types can create significant problems later. The goal isn't to prescribe one design for every application. Instead, it provides a way to reason through CAD scenarios and real development work by starting with what the application actually needs to represent and choosing the ServiceNow structures that express those concepts most naturally.
ServiceNow applications can look deceptively simple from the user's perspective. A user opens a menu, selects a module, works with a list or form, changes a field, and clicks a button. Behind those few interactions, however, the platform may be coordinating navigation, client-side behavior, server-side processing, security, UI actions, and application logic. This Breakdown takes a closer look at that hidden machinery. Instead of treating forms, lists, UI Policies, Client Scripts, UI Actions, ACLs, and related components as isolated features to memorize, it examines how they participate in the user's experience and, more importantly, where their responsibilities begin and end. The article also tackles an important development distinction: making something happen in the interface is not necessarily the same as enforcing a rule in the application. Understanding that boundary—and knowing what should happen when a record is changed somewhere other than the form—is essential to building ServiceNow applications that behave consistently and securely.
Building a ServiceNow application involves much more than creating a table and putting a form on top of it. This Breakdown looks at the different pieces that make up an application—from data models, tables, and fields to navigation, user interfaces, application logic, security, scope, and application artifacts—and explains how they fit together. Rather than treating these as unrelated ServiceNow features, this article looks at the decisions a developer actually has to make when turning a business requirement into a working application. It provides a practical foundation for understanding the architecture behind ServiceNow applications and the reasoning that drives good development decisions.
Request missing content
No labs available