Home/ crm-business-applications/ ServiceNow Certified Application Developer/ Cheat Sheet
ServiceNow Certified Application Developer· Exam reference card · 2026 · Edureify AI
ServiceNow Certified Application Developer

ServiceNow Certified Application Developer Cheat Sheet

ServiceNow CAD Tests Platform Development Judgment — Configuration Before Code

ServiceNow development follows a clear principle: configure before you code. Candidates who jump to scripting when declarative configuration solves the problem fail platform architecture questions.

Check Your Readiness →
Among the harder certs
Avg: Approximately 62–67%
Pass: 750 / 1000
Most candidates understand ServiceNow Certified Application Developer concepts — and still fail. This exam tests how you apply knowledge under pressure.
Core Framework

ServiceNow Development Priority Hierarchy

ServiceNow CAD tests application development on the Now Platform. The exam covers application scope, data model design, scripting, UI development, and integration. Every decision should prefer declarative configuration over custom scripting to maintain upgradability.

  1. 01
    1. Configuration — Use OOB (out of box) features first
  2. 02
    2. Customization — Declarative tools: Forms, Lists, UI Policies, Business Rules
  3. 03
    3. Scripting — Client-side (GlideForm) and server-side (GlideRecord)
  4. 04
    4. Integration — REST/SOAP APIs, Import Sets, Integration Hub
  5. 05
    5. Testing — ATF (Automated Test Framework) for regression testing
Scenario Traps

Wrong instinct vs correct approach

A field needs to become mandatory only when another field has a specific value
✕ Wrong instinct

Write a Business Rule to enforce the mandatory field

✓ Correct approach

Use a UI Policy — UI Policies handle client-side conditional field visibility and mandatory state without scripting. Business Rules run server-side and are the wrong tool for immediate client-side form behavior.

A custom application needs to read and update records across multiple tables
✕ Wrong instinct

Use direct SQL to query the ServiceNow database

✓ Correct approach

Always use GlideRecord for database operations in ServiceNow — it respects access controls, business rules, and the platform's security model. Direct SQL bypasses all platform controls.

A development team needs to move customizations from dev to production
✕ Wrong instinct

Manually recreate the customizations in production

✓ Correct approach

Create an Update Set capturing all changes, test in staging, then deploy the Update Set to production — manual recreation is error-prone and untraceable

Quick Rules

Know these cold

  • ▸ Configure before you code — OOB features, then declarative tools, then scripts
  • ▸ UI Policies for client-side field behavior; Business Rules for server-side logic
  • ▸ GlideRecord for all database operations — never direct SQL
  • ▸ Always develop in application scope — avoid global scope for new applications
  • ▸ Update Sets capture and transport customizations between instances — always use them
  • ▸ Client Scripts run in browser (GlideForm); Business Rules run on server (GlideRecord)
  • ▸ ATF enables regression testing — write tests with your code
Self Check

Can you answer these without checking your notes?

In this scenario: "A field needs to become mandatory only when another field has a specific value" — what should you do first?
Use a UI Policy — UI Policies handle client-side conditional field visibility and mandatory state without scripting. Business Rules run server-side and are the wrong tool for immediate client-side form behavior.
In this scenario: "A custom application needs to read and update records across multiple tables" — what should you do first?
Always use GlideRecord for database operations in ServiceNow — it respects access controls, business rules, and the platform's security model. Direct SQL bypasses all platform controls.
In this scenario: "A development team needs to move customizations from dev to production" — what should you do first?
Create an Update Set capturing all changes, test in staging, then deploy the Update Set to production — manual recreation is error-prone and untraceable
Failure Patterns

Common Exam Mistakes — What candidates get wrong

Writing custom scripts when Business Rules or UI Policies suffice

Business Rules (server-side) and UI Policies (client-side) handle most common field validation and automation without scripting. Custom scripts are harder to maintain and upgrade — candidates who jump to scripts fail platform architecture questions.

Confusing client-side and server-side scripts

Client-side scripts (Client Scripts, UI Actions on client) run in the browser and interact with form fields via GlideForm. Server-side scripts (Business Rules, Script Includes) run on the server and interact with the database via GlideRecord. Mixing contexts causes runtime errors.

Not scoping applications correctly

ServiceNow applications must be developed in application scopes to isolate customizations and prevent interference with other apps. Developing in the global scope is bad practice for applications.

Ignoring the Update Set workflow

All ServiceNow customizations must be captured in Update Sets for transport between instances (dev → test → production). Candidates who don't capture customizations in Update Sets lose work during instance migrations.

Confusing the Now Platform data model

Tables extend parent tables and inherit fields. Task table is the parent of Incident, Change, Problem, etc. Creating a new table when extending an existing one is appropriate requires understanding this hierarchy.

ServiceNow CAD tests platform development judgment. Test whether you know when to configure vs. when to code.

Start Diagnostic Test → View all exams