CAD study guide: pass the ServiceNow Certified Application Developer exam

The Certified Application Developer exam is for people who build on ServiceNow rather than just configure it: developers who write the business rules, design the tables, wire the integrations, and ship scoped applications. If the CSA proved you understand the platform's map, the CAD proves you can construct new territory on it.

Who should take it? Admins who have drifted into scripting and want to make it official. Developers arriving from other stacks who need to learn where ServiceNow rewards and punishes their instincts. Consultants who build custom apps for clients. The honest value: the CAD carries more technical weight with hiring managers than the CSA because it is harder to pass on memorization alone. It will not make you a good developer by itself, but preparing for it properly closes the exact gaps that separate "I can write a business rule" from "I can ship an application that survives an upgrade." CSA first is the recommended baseline, and I agree with the recommendation: the CAD assumes the CSA mental model and builds on it without re-teaching it.

The exam at a glance

Like the CSA, the CAD is a proctored, closed-book, multiple-choice exam booked through Now Learning, online or at a test center, in the region of 60 questions and 90 minutes. The blueprint has held roughly this shape:

Domain	What it covers	Approximate weight
Designing and creating an application	Scoped apps, Studio, table design, application files	~20%
Application user interface	Forms, UI policies, UI actions, client scripts	~10%
Security and restricting access	ACLs in scope, roles, cross-scope access	~20%
Application automation	Flow Designer, actions, notifications, scheduled jobs	~20%
Working with external data	Import sets, REST, Scripted REST APIs	~10%
Testing, source control, and deployment	ATF, Git in Studio, app repository, update sets	~20%

Read the weights and notice the story they tell: 40 percent of this exam is security plus shipping. Candidates who only practice scripting walk in strong on 30 percent of the paper and get quietly murdered by ACL evaluation and app repo questions.

Before you start

Hold the CSA, or at minimum be at CSA level without the paper. If table extension, update sets, or the client-versus-server split feel wobbly, fix that first; the CAD assumes it.

You want real scripting exposure. Not mastery, but you should have written and debugged a handful of business rules and client scripts before starting the clock. JavaScript fundamentals matter too: the server side runs Rhino, an older engine, so ES5 habits (var, classic functions) are what you will see in questions and what you should practice in.

And you need a PDI with an application of your own on it. Not exercises scattered across global scope: one scoped application, built end to end. The whole study plan below is organized around that build, because the CAD is an exam about application development and the only way to be good at that is to develop an application.

The concepts that actually matter

Scope: the walls around your application

Everything on the modern platform starts here, so we will too. A scoped application is a namespace: its tables, scripts, and configuration live under a prefix like x_acme_fleet, and the platform enforces boundaries around what code inside the scope can touch and what code outside can touch back.

Why does scope exist? Because global scope is a shared kitchen with no labels on anything. Before scoping, every custom business rule, every script include, every table sat in one namespace where anything could modify anything, name collisions were a real risk, and two vendors' apps could quietly corrupt each other's logic. Scope turns applications into packages with defined surfaces. It is also what makes the ServiceNow Store possible: you can install a third-party app knowing it cannot rummage through your incident table unless you let it.

The gotchas are where the exam lives. Know these cold:

• Each application defines what other scopes may do with its tables: can they read, write, create ACLs, write scripts against them? These are per-table application access settings, and the defaults are conservative.
• Script includes have an accessibility setting: callable from this scope only, or from all scopes. A cross-scope call to a private script include fails, and that failure is a favorite question.
• Your session has a current application, and configuration records land in whatever scope is current. Editing a global business rule while your scope is set to your app (or the reverse) creates a mess that update sets and the app repo will faithfully preserve.
• Some APIs are restricted in scope. Scoped scripts get GlideRecord but not everything global scripts enjoy; certain methods and direct database operations are fenced off, and the platform offers scoped-safe equivalents.

Table design: extend, reference, or stand alone

Every application starts with a data model, and the CAD tests whether you can make the three-way call: extend an existing table, create a standalone table, or model the relationship with references instead.

Extend task when your record is work that people are assigned and that flows through states. You inherit the fields, the SLA engine, assignment, approvals, and visibility in task-based reporting for free. Do not extend task for things that are not work: extending it for a "vehicle" record because extension seemed fancy is a design smell the exam will happily present as a tempting option.

Create a standalone table for entities: vehicles, vendors, policies. Extend your own base table when you have genuine specialization with shared fields and shared behavior. Use reference fields for "points at" relationships and many-to-many tables when both sides need multiples.

Here is the data model of the sample app this guide builds, a small fleet management application, the way I would sketch it:

task
└── x_acme_fleet_request          work: gets states, assignment, SLAs for free

x_acme_fleet_vehicle              entity: standalone base table
├── x_acme_fleet_vehicle_car      specialization via extension
└── x_acme_fleet_vehicle_truck

x_acme_fleet_service_log          flat table, reference field to vehicle
x_acme_fleet_vendor               flat table, referenced by service_log

If you can defend every line of a sketch like that (why extend here, why reference there), you are ready for the design questions. Also know the supporting cast: auto-numbering, dictionary overrides (a child table changing an inherited field's behavior for itself only), and what deleting a table actually removes.

Server scripting: GlideRecord, business rules, script includes

GlideRecord is the platform's query API and the exam expects fluency, not familiarity. The canonical patterns:

// query a set of records
var gr = new GlideRecord('x_acme_fleet_request');
gr.addQuery('state', '2');
gr.addQuery('vehicle.model', 'CONTAINS', 'Transit'); // dot-walk in a query
gr.orderByDesc('sys_created_on');
gr.setLimit(50); // sampling? say so with a limit
gr.query();
while (gr.next()) {
    gs.info('Open request: ' + gr.getValue('number'));
}

// fetch one record by a stable field, not a hardcoded sys_id
var vehicle = new GlideRecord('x_acme_fleet_vehicle');
if (vehicle.get('asset_tag', 'FLT-0042')) {
    vehicle.setValue('status', 'in_service');
    vehicle.update();
}

Know the difference between get() (returns true and positions on the record) and query-plus-next, know addEncodedQuery, deleteRecord versus deleteMultiple, and know that setWorkflow(false) suppresses business rules and engines while autoSysFields(false) stops the system fields from updating, both tools you reach for deliberately in data fixes and never casually.

Business rules you know from CSA; the CAD deepens the timing questions. Before rules mutate current with no update() call needed (calling update in a before rule is a classic wrong answer). After rules run once the database has the record, the right place to update other records. Async rules run later, off the user's transaction, for slow work. Display rules populate g_scratchpad for the client. current and previous are available and the exam will test that previous is not available in async rules.

Script includes are where reusable server logic lives. Three flavors matter: on-demand classes you instantiate, classes extending AbstractAjaxProcessor so the client can call them, and extension of other script includes. One shape to have in your fingers:

var FleetUtils = Class.create();
FleetUtils.prototype = {
    initialize: function() {},

    openRequestCount: function(vehicleSysId) {
        var ga = new GlideAggregate('x_acme_fleet_request');
        ga.addQuery('vehicle', vehicleSysId);
        ga.addActiveQuery();
        ga.addAggregate('COUNT');
        ga.query();
        return ga.next() ? parseInt(ga.getAggregate('COUNT'), 10) : 0;
    },

    type: 'FleetUtils'
};

GlideAggregate for counting instead of looping a GlideRecord is exactly the kind of judgment the better questions probe.

Client scripting: g_form, UI policies, GlideAjax

The client side is g_form territory: getValue, setValue, setMandatory, setVisible, setReadOnly, showFieldMsg, plus g_user for role checks in the UI (never for security, which is ACLs' job). The CSA-era rule still governs: UI policies for simple show/hide/mandatory logic, client scripts when you need actual code, and nothing client-side is enforcement.

The topic the CAD adds, and tests hard, is how the client talks to the server without freezing the browser. Direct GlideRecord queries from client scripts are the tempting wrong answer: synchronous, slow, and blocked in scoped apps for good reason. The right answer is GlideAjax with a callback:

// client script (onChange)
function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading || newValue === '') return;

    var ga = new GlideAjax('x_acme_fleet.FleetAjax');
    ga.addParam('sysparm_name', 'getOpenCount');
    ga.addParam('sysparm_vehicle', newValue);
    ga.getXMLAnswer(function(answer) {
        if (parseInt(answer, 10) > 0)
            g_form.showFieldMsg('vehicle', 'This vehicle has open requests', 'info');
    });
}

The server half extends AbstractAjaxProcessor, must be client callable, and returns its value from the named method. Know this round trip and know the alternatives for pre-loading data: g_scratchpad filled by a display business rule when you know at load time what the form will need, getReference with a callback for one referenced record. Asynchronous with a callback is nearly always the right pattern; anything synchronous on the client is nearly always wrong.

Automation: Flow Designer first, workflow when you must

Flow Designer is the platform's automation engine of record and the CAD treats it as such. A flow is a trigger (record created or updated, scheduled, application-driven) plus a sequence of actions with data pills flowing between them. Actions are reusable units built in the action designer, from no-code steps or from script steps when needed, and spokes are bundles of actions an application publishes. Subflows are flows callable from other flows or from script. Build custom actions for your app's repeated logic instead of copy-pasting script steps: that is both the best practice and the expected answer.

Classic Workflow (the graphical editor on wf_workflow) still exists and still runs a great deal of the installed base, so the exam expects you to know what it is, that legacy processes and some older catalog items use it, and that new development belongs in Flow Designer. The comparison questions are gimmes if you remember one line: flows are the present, workflows are maintained history.

Round out this domain with the rest of the server-side automation family: scheduled jobs and scheduled script executions, events and the event queue (gs.eventQueue, event registry, notifications or script actions responding), and email notifications triggered by events or record conditions.

Opening the doors: REST and application security

Two halves here, and the exam weights them heavily.

Inbound integration starts with the REST API Explorer and the out-of-box Table API: any table, standard CRUD, controlled by the caller's credentials and ACLs. When the out-of-box shape does not fit (you need a custom resource path, custom logic, a stable contract that hides your table structure), you build a Scripted REST API: an API with a namespace, resources with HTTP methods, and scripts receiving request and response objects. Know how path parameters and query parameters are read, and know that authentication and ACLs still apply, Scripted REST is not a security bypass.

Security in a scoped app is CSA ACL knowledge plus the scope dimension. ACLs protecting your app's tables live in your scope. Evaluation is unchanged (most specific first, field and table level must both pass), and the design expectation is that your app ships its own roles, assigns them meaning through ACLs, and declares honest cross-scope table permissions rather than flinging everything open. The classic exam scenario gives you another scope's script failing to read your table and asks why: the answer is almost always the application access settings on the table or the accessibility of the script include, not a missing ACL.

Shipping: source control, ATF, and deployment paths

This is the domain that separates application developers from script writers, and the exam knows it.

Studio connects a scoped app to a Git repository: you link a repo, commit changes, create branches, switch branches (stashing local changes), and apply remote changes made by teammates. Every application file, the tables, scripts, ACLs, all of it, is versioned as XML in the repo. Know the vocabulary as Studio uses it and know what happens when two developers edit the same file (last apply wins locally; the process, not magic, prevents pain).

Deployment has two paths and choosing correctly is tested repeatedly. Scoped applications move between instances through publish and install: publish a version to the application repository from dev, install that version on test and prod, with rollback to a prior version available. Update sets still exist and still work for global-scope configuration and for patching, but the app repo is the designed path for applications, it carries versioning, and it is the expected answer for moving a scoped app. If a question offers both, look for the noun: application, use the app repo; loose global configuration, update set.

Build in Studio on devEvery artifact is an application file in your scope, tracked automatically, no update set bookkeeping

Commit to source controlStudio pushes application files to the linked Git repo; branches carry parallel work

Run ATF suitesAutomated tests verify forms, server logic, and API behavior before anything leaves dev

Publish to the app repositoryA numbered version of the app becomes installable by your other instances

Install on test, then prodSame version everywhere, rollback available, no manual collision surgery

ATF, the Automated Test Framework, is the testing story: tests composed of steps (open a form, set values, assert conditions, run server script assertions), organized into suites, runnable on schedules. Two facts to lock in: ATF test execution is disabled by default on production instances via a system property, deliberately, and tests should run on non-prod where rollback of test data is handled by the framework. Quick-start tests shipped with applications give you templates to copy.

A six week study plan

The spine of this plan is one scoped app, the fleet application above, built a layer per week. Eight to ten focused hours a week.

Week one: scope and skeleton. Create the scoped app in Studio. Build the tables from the tree diagram: request extending task, vehicle as a standalone base with two extensions, service log and vendor as flat tables. Set application access on each table and write down why. Explore what Studio tracked for you.

Week two: server logic. Business rules on the request table (one before, one after, one async, and note what previous does in each). The FleetUtils script include. A scheduled job that flags overdue requests. Practice GlideRecord until the patterns above flow without reference.

Week three: the client layer. Form layout, UI policies for state-driven behavior, an onChange client script, the GlideAjax round trip end to end, a UI action (with a client-and-server combination at least once). This week kills the client/server confusion permanently.

Week four: automation and integration. A flow triggered by request creation that assigns work and sends a notification; one custom action with a script step; a subflow. Then a Scripted REST API exposing vehicle status, tested from the REST API Explorer and from curl.

Week five: security and shipping. Roles for the app, ACLs for every table, impersonation testing. Link Studio to a Git repo, commit, branch, make a change on a branch, merge it back. Publish the app and, if you have a second instance available, install it there. Write two ATF tests and a suite.

Week six: consolidate and drill. Rebuild anything shaky. Practice questions diagnostically: a miss means re-lab the topic. Reread the blueprint on Now Learning and self-score. Book the exam for the end of the week.

Hands-on labs on your PDI

If you followed the plan you have done most of these; here they are as discrete, checkable exercises.

1. Scope collision hunt. With your app as the current application, try to modify a global business rule. Read the warning. Switch scopes and observe the difference in where records land. Ten minutes, permanent lesson.
2. Design defense. For each table in the fleet app, write one sentence justifying extend versus standalone versus reference. If you cannot, redesign it.
3. The before/after experiment. Write a before rule that sets a field and an after rule that tries to set a field the same way. Observe that the after rule's change is not on the saved record without an explicit update, and note the extra update it costs.
4. GlideAjax round trip. Build the FleetAjax script include and the onChange script that calls it. Break it three ways on purpose: wrong sysparm_name, script include not client callable, wrong scope prefix in the GlideAjax constructor. Learn the error signature of each.
5. Scripted REST contract. Build a GET resource returning a vehicle's open request count as JSON. Call it with the REST API Explorer, then with basic auth from outside. Then remove your test user's role and watch the ACLs deny it.
6. Branch and merge. In Studio's source control, create a feature branch, add a field on the branch, switch back, and apply the change through the repo. This one exercise answers most source control questions on the paper.
7. Publish, break, roll back. Publish version 1.0 of your app. Make a deliberately bad change, publish 1.1, then roll back. Knowing rollback exists is a fact; having done it is an answer.
8. ATF suite. One form test (create request, assert a UI policy fired), one server test (run FleetUtils, assert the count). Put both in a suite and run it on a schedule once.

How the questions try to trick you

Scope sleight of hand. A script in scope A reads a table in scope B and fails. The distractors blame ACLs; the answer is usually application access settings or script include accessibility. Check the walls before the locks.

The synchronous temptation. Any client-side option that queries the database directly or calls the server synchronously is bait. Asynchronous GlideAjax with a callback is the pattern the exam rewards, every time.

update() in a before rule. It appears as a plausible answer and it is wrong: before rules modify current and the platform saves it. Extra update calls in the wrong context cause recursion and double-fire questions, which the exam also asks about.

Workflow nostalgia. Questions offering classic workflow for new automation. New development is Flow Designer; workflow answers are correct only when the question is explicitly about maintaining existing legacy processes.

Deployment verb confusion. "Move the application to production" with update set answers available. Applications ship through publish and install via the app repository. Update sets are for global configuration and patches.

Security theater. Options that "secure" data with client scripts, hidden fields, or UI policies. Enforcement is ACLs on the server, full stop, and the exam checks that conviction more than once.

Exam week checklist

• Self-score the official blueprint line by line; spend remaining hours only on the red items.
• Redo labs 4, 6, and 7 without notes: GlideAjax, source control, publish and rollback cover the two heaviest domains.
• Rehearse the ACL evaluation order and the business rule timing table until you can recite both.
• Verify your proctoring setup (ID, webcam, clean desk) the day before if testing online.
• In the exam, mark the scenario questions long enough to name the concept being tested before reading the options. The CAD hides one concept per question under two paragraphs of story.
• Flag and move on when stuck; second-pass accuracy is better than first-pass stubbornness.

After you pass

Keep it current: delta exams arrive with platform releases through Now Learning, short and unproctored, and doing them on time is far cheaper than recertifying.

Then decide what kind of builder you are becoming. If you gravitate toward process and implementation, a CIS track (ITSM, or the domain you work in) stacks well on CAD. If you are heading toward architecture, start collecting the habits now: insist on scoped apps, keep apps in source control, write ATF tests before someone makes you. And build something real on your PDI that is not an exercise, a whole application solving an actual problem you have. The certificate says you can develop applications on the Now Platform. The application is the part people will actually ask to see.