DEV Community

ExamCert.App
ExamCert.App

Posted on

Don't Read the ServiceNow CSA. Build It: A PDI Walkthrough for Developers

ServiceNow Certified System Administrator (CSA)

Every CSA study guide tells you to "review the exam blueprint." Nobody tells you that the fastest way to lose two weeks is to read about ACL evaluation order instead of writing an ACL that breaks and then figuring out why.

I'm a developer. I came to ServiceNow sideways, from a Node/Python background, and the thing that finally clicked was treating my Personal Developer Instance like a scratch repo. Every domain in the blueprint maps to something you can build in about 20 minutes. So that's what this post is: the build order I'd use again, with the actual scripts.

The exam, in one paragraph

60 questions, 90 minutes, multiple choice and multiple select. Voucher is typically around $150 USD, and ServiceNow gates registration behind completing the Administration Fundamentals course on Now Learning — the on-demand version is free, so budget the hours, not the dollars. ServiceNow doesn't publish an official cut score; everyone who's sat it converges on "aim for 70%+ and stop worrying about it." The ServiceNow CSA exam overview has the current format if the blueprint shifts under you, which it does with each platform release.

Six domains, roughly weighted like this:

Domain Weight
Self-Service & Process Automation 22%
Platform Overview & Navigation 16%
Configuring Applications for Collaboration 16%
Database Administration 16%
Introduction to Development 16%
Instance Configuration 14%

Notice the top slice. Flows, approvals, notifications, service catalog. That's where a fifth of your marks live, and it's also the part you can only really learn by clicking through it.

Step 0: Get a PDI and don't let it hibernate

developer.servicenow.com, sign up, request an instance. It provisions on the current release in a couple of minutes. One gotcha that cost me a weekend: PDIs hibernate after about 10 days of inactivity, and if you leave one alone long enough it gets reclaimed and you lose everything. Log in and poke it twice a week. Set a calendar reminder. I'm serious — I rebuilt a whole catalog item once because I went on holiday.

Step 1: Break the data model on purpose

Go to All → System Definition → Tables, open incident, and look at the "Extends table" field. It says task. That single fact is half the Database Administration domain.

ServiceNow uses table extension the way you'd use class inheritance. task is the parent; incident, problem, change_request, sc_req_item all extend it. Fields defined on task (number, short_description, assigned_to, state) exist on every child. Fields defined on incident (caller_id, category, subcategory) do not exist on problem.

Now build a table yourself. Create u_hardware_request, extend it from task, add two fields, and watch the platform hand you a number prefix, a form, a list, and an activity stream for free. Then ask yourself the question the exam asks constantly: if I add a field to the parent, what happens to the child? (Nothing you'd hate. It shows up.)

Step 2: Live in Scripts - Background

This is the ServiceNow REPL. All → System Definition → Scripts - Background. It runs server-side JavaScript against your instance with no guard rails, which is exactly why you should only ever do it on a PDI.

The one API you must be fluent in is GlideRecord. Type this in and run it:

// Find every P1 incident that's still open and older than a week
var gr = new GlideRecord('incident');
gr.addQuery('priority', 1);
gr.addQuery('active', true);
gr.addQuery('sys_created_on', '<', gs.daysAgo(7));
gr.orderBy('sys_created_on');
gr.query();

gs.info('Found ' + gr.getRowCount() + ' stale P1s');

while (gr.next()) {
  gs.info(gr.getValue('number') + ' | ' +
          gr.getDisplayValue('assigned_to') + ' | ' +
          gr.getValue('short_description'));
}
Enter fullscreen mode Exit fullscreen mode

Three things in that snippet are exam material and job material at the same time:

  • getValue() returns the raw database value; getDisplayValue() returns what the user sees. On a reference field like assigned_to, getValue() gives you a 32-character sys_id and getDisplayValue() gives you "Beth Anglin." People get this wrong in production every day.
  • addQuery() chains with implicit AND. If you want OR, you need addOrCondition() on the returned query object — a genuinely common trip-up.
  • gr.query() actually executes. Forget it and your while loop silently does nothing, which is the single most confusing five minutes a new ServiceNow dev will ever have.

Want the query syntax without writing it? Build the filter in a list view, right-click the breadcrumb, "Copy query," and paste it into gr.addEncodedQuery('...'). That trick alone is worth the price of admission.

Step 3: Build one flow end to end

Now the 22% domain. Flow Designer → New → Flow.

Build this, exactly this:

  • Trigger: Record created → table sc_req_item
  • Condition: Catalog item is your new hardware request
  • Action 1: Ask for Approval → approver = the requester's manager (Requested for → Manager)
  • Action 2 (if approved): Create Task on sc_task, assignment group = Hardware
  • Action 3 (if rejected): Send Notification to the requester

Then submit a request as a test user and watch it run. Open the flow's execution details and step through the context — every input, every output, every data pill. Ten minutes of staring at a real flow context teaches you more about the request/RITM/task relationship than any diagram will.

The exam loves that relationship. sc_request is the shopping cart. sc_req_item (RITM) is the line item. sc_task is the work someone actually does. If you can't say which record the approval hangs off, you'll drop points.

Step 4: The domain that fails people

Access controls. ACLs.

Here's the rule that gets tested: for a user to see or edit a record, they must pass table-level AND field-level checks, evaluated most-specific-first. incident.number is checked before incident.*, which is checked before *.*. And within a single ACL, the condition, the script, and the role requirement must all pass. Not one of them. All of them.

Create a field-level read ACL on incident.caller_id, restrict it to itil, then impersonate a user without that role. The field vanishes. Now you understand it. Trying to memorize this from a slide is how people fail.

While you're impersonating: elevate to security_admin first (top-right user menu → Elevate role), or the ACL module won't even be editable. That's a five-minute confusion I'd rather you skip.

What I'd skip

Don't grind hundreds of practice questions on week one — you'll be memorizing vocabulary you have no hooks for. Build first for three weeks, then drill. Once you've got the muscle memory, question volume is what exposes the gaps you didn't know you had; I ran mine through ExamCert in the last stretch and it caught two whole areas I'd been quietly avoiding (import sets, and update set collision behavior — both boring, both testable).

If you want a temperature check before you commit a voucher, run a set of free practice questions cold, no studying. Whatever score you get, that's your honest baseline, and it's usually humbling in a useful way.

Four to six weeks of evenings is a realistic timeline for a developer who already knows JavaScript and relational data. Less if you're already working in an instance daily. The platform isn't hard. It's just specific, and specificity only comes from touching it.

Top comments (0)