Overview
Designing and Creating an Application covers the first decisions a ServiceNow developer makes: whether a business need belongs on the platform at all, how to model its data in tables and fields, how users will reach the application through an application menu and modules, and which application scope will own every file you create. The four official objectives are small in number but broad, because each one is a design choice with consequences.
The domain is the foundation for the rest of the exam. Forms and client scripts in Domain 2 sit on top of the tables you design here, the access controls in Domain 3 are generated when you create those tables, automation in Domain 4 listens to their records, and Domain 6 packages the scope you chose for installation and source control. A weak data model or a wrong scope shows up later as broken references, missing fields and cross-scope errors.
How it's tested
Domain 1 questions are short design scenarios. A stakeholder describes a process, and you choose the right fit decision, table structure, module type or scope setting. Many answers are all technically possible, so the test is which one follows platform best practice: reuse inherited capability, keep work inside its own scope, and avoid modifying baseline tables when an extension will do.
-
Fit or no fit
A requirement is described and you decide whether it suits the platform. Structured records, approvals, assignment and reporting point to yes; heavy media processing or intensive computation points to no.
-
Choose the table design
You pick between extending Task, extending another table, a standalone table, a reference field or a many-to-many relationship, based on the behavior the data needs.
-
Scope consequences
A developer builds or edits something and you predict the result of the current application setting, the scope prefix, or the table's application access options.
A scenario says HR wants to track equipment loans with assignment groups, states and SLAs, and offers four table designs. Ask which behaviors are required, then which parent already supplies them. Task provides assignment, state, work notes and SLA hooks; Incident provides them too but adds IT-specific rules and access controls. The answer is the design that reuses Task without modifying it or inheriting another application's logic.
Objectives 4
Official objectives from the ServiceNow outline, in outline order.
1.1 Determine if an application is a good fit with ServiceNowMatching a business need to what the platform does well.
- What it means
- ServiceNow is built for record-based work: structured data that moves through states, gets assigned to people or groups, needs approvals and notifications, and is reported on. A good-fit application replaces spreadsheets, email chains or paper forms that already follow a repeatable process.
- What to understand
- Fit is judged by the shape of the work, not by whether code could make it run. Multiple users collaborating on records, a defined lifecycle and a need for audit history are strong signals; workloads centered on video, image editing, real-time gaming or heavy numerical computation are poor fits.
- How it shows up
- A department describes its current process, and you decide whether to build it on ServiceNow or which characteristic makes it a poor candidate.
- Common confusion
- Candidates assume that anything scriptable is a good fit. The exam asks whether the platform's built-in record, workflow and reporting strengths do the heavy lifting.
1.2 Design and implement a data modelTables, fields, extension and relationships.
- What it means
- A data model is the set of tables, columns and relationships an application stores. You create tables (optionally extending an existing one), add fields of the right type, and link records with reference fields or many-to-many relationships.
- What to understand
- Extending a table makes the child inherit every parent field and the parent's behavior; extending Task brings number, state, assignment group, assigned to, work notes, approvals and SLA support. A reference field stores a sys_id and creates a one-to-many link; a many-to-many table is needed when both sides can have many partners. Records of a child table also appear when you query the parent.
- How it shows up
- A requirement lists the behaviors a record needs, and you choose the parent table or relationship type that supplies them with the least custom work.
- Common confusion
- Extending Incident or another application table instead of Task drags in that application's business rules, access controls and licensing; Task is the neutral base for work records.
1.3 Create modulesApplication menus and the links users click.
- What it means
- An application menu groups modules in the application navigator, and each module is a link with a type such as List of Records, New Record, Single Record, Run a Report, URL, Separator or Script. Modules can carry a filter, an order value and roles.
- What to understand
- A List of Records module with a filter (for example, assigned to the current user and active) gives each user a tailored view without new tables or scripts. Roles on a module or menu control visibility in the navigator but do not secure the underlying data; access controls do that.
- How it shows up
- A scenario asks how to give users a one-click view such as 'My open requests', or why a user sees a module but still cannot open the records.
- Common confusion
- Candidates treat hiding a module as security. A user who knows the table URL can still reach the list unless access controls block the data.
1.4 Use Application scopeThe namespace that owns and protects an application's files.
- What it means
- A scoped application has a unique namespace, formed as x_ plus the vendor prefix plus an application identifier. Tables, script includes and other files created in that scope carry the namespace, and the platform enforces boundaries between scopes.
- What to understand
- Work is recorded into whichever application is selected as the current application, so the application picker or the scope chosen in ServiceNow Studio decides where a file lands. Scoped scripts use the scoped API, so methods such as gs.log are not available and gs.info, gs.warn, gs.error or gs.debug replace them. A table's application access settings decide whether other scopes can read, create, update or delete its records.
- How it shows up
- A developer finds a new table or business rule in the wrong application, or another app cannot read a table, and you identify the scope setting responsible.
- Common confusion
- Global scope is not 'no scope'. It is its own scope with fewer protections, and building custom applications there gives up isolation and clean packaging.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Task table extension
Extending Task gives a new table the number field, state, priority, assignment group, assigned to, work notes, approvals and SLA support without writing code.
- Remember
- Choose Task as the parent whenever records are units of work that people are assigned to and progress through states.
- Tested as
- It is the default correct answer when a scenario lists assignment, work notes or SLAs as requirements.
- Trap
- Extending Incident or Change for convenience, which inherits ITSM-specific logic and access rules the new application should not carry.
-
Scoped namespace prefix
Scoped application files carry a namespace built from x_, the instance's vendor prefix and the application identifier, so a table might be named x_acme_loans_request.
- Remember
- The prefix comes from the instance's vendor prefix and the application, not from the developer, and the scope name is fixed once the application is created.
- Tested as
- Questions ask you to recognize which application owns a table or script from its name.
- Trap
- Expecting the global u_ prefix on scoped tables; u_ belongs to custom tables and fields created in the global scope.
-
Current application (application picker)
The platform records each new or changed configuration file into the application currently selected, whether you picked it in the navigator's picker or opened the app in ServiceNow Studio.
- Remember
- Check the current application before you create anything; the platform does not guess the right one.
- Tested as
- Troubleshooting questions describe files that ended up in the wrong scope.
- Trap
- Blaming a bug or permissions when the real cause was building while the wrong application was selected.
-
Reference field
A reference field stores the sys_id of a record on another table and displays that record's display value, creating a one-to-many relationship that supports dot-walking.
- Remember
- Many records can point to one referenced record; the reference lives on the 'many' side.
- Tested as
- Data-model questions ask which field type links a child record to its parent, such as a loan to a piece of equipment.
- Trap
- Using a string field holding a name, which breaks when the name changes and loses dot-walking and reference qualifiers.
-
Many-to-many relationship
When both sides can have many partners, such as equipment and approved user groups, a many-to-many table holds one row per pairing with a reference to each side.
- Remember
- A single reference field cannot model many-to-many; you need the intermediate table.
- Tested as
- Scenarios describe 'each X can have many Y and each Y many X' and ask for the structure.
- Trap
- Choosing a reference field on one side, which allows only one partner per record.
-
Table inheritance and sys_class_name
Records in a child table are also records of the parent; the sys_class_name field tells you which child class a parent-table row belongs to.
- Remember
- Querying the parent returns child records too, and parent-level business rules and access controls apply to children unless overridden.
- Tested as
- Explains why a Task-level rule fires on a custom table's records.
- Trap
- Assuming a child table is an isolated copy of the parent's columns.
-
Table creation side effects
Creating a table with the default options can also create an application menu module, a user role and create, read, write and delete access controls for the new table.
- Remember
- Those generated access controls require the generated role, so users without it cannot see records until the role is assigned.
- Tested as
- Questions ask why a newly built table's records are invisible to testers.
- Trap
- Thinking new tables are open to everyone by default.
-
Module link types
Common types are List of Records, New Record, Single Record, Run a Report, URL (from arguments), Script (from arguments) and Separator.
- Remember
- A filtered List of Records module is the low-code way to give a personal queue.
- Tested as
- You pick the type that matches a navigation requirement.
- Trap
- Writing a scripted module or a new table when a filter on a list module solves it.
-
Application fit signals
Strong signals are structured data, multiple collaborating users, defined states, approvals, notifications, audit history and reporting needs.
- Remember
- Weak signals are rich media handling, intensive calculation and processes with no repeatable structure.
- Tested as
- Opening questions in the domain test this judgment directly.
- Trap
- Treating 'could be scripted' as 'is a good fit'.
-
Scoped logging API
Scoped scripts log with gs.info, gs.warn, gs.error and gs.debug; gs.log and gs.print are global-only.
- Remember
- If a scoped script calls gs.log, it fails rather than writing to the log.
- Tested as
- Appears when a scenario's script works in global but not in the new scoped app.
- Trap
- Assuming every GlideSystem method behaves the same in both scopes.
-
Global scope
Global is a scope that most baseline applications and legacy custom work live in, with fewer isolation protections than a private application scope.
- Remember
- New custom applications should normally be scoped so they can be isolated, versioned and installed cleanly.
- Tested as
- Design questions ask where a new custom application should be built.
- Trap
- Building custom apps in global because it avoids cross-scope configuration.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Extend Task vs. extend another application table vs. standalone table
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Extend Task | New table inherits Task fields and behavior | Gets number, state, assignment, work notes, approvals and SLA support | Skipping it and rebuilding those fields by hand |
| Extend Incident or Change | New table inherits an ITSM application's table | Also inherits that application's business rules, ACLs and licensing scope | Choosing it because Incident 'looks similar' |
| Standalone table | Table with no parent | Only system fields; suits reference data that is not assigned work | Using it for work items that need assignment and SLAs |
Reference field vs. many-to-many table vs. list field
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Reference field | Stores one sys_id pointing to another record | One-to-many; supports dot-walking and reference qualifiers | Using it when each side needs many partners |
| Many-to-many table | Intermediate table with a reference to each side | Models true many-to-many and can store attributes of the pairing | Forgetting it is a table you must create and relate |
| List (glide_list) field | Comma-separated sys_ids in one field | Quick multi-select, but weak for reporting and querying | Treating it as a full relational design |
Scoped application vs. global scope
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Scoped application | Private namespace prefixed x_vendor_app | Files are protected; other scopes need application access or cross-scope privileges | Expecting global-only APIs such as gs.log to work |
| Global scope | Shared namespace for baseline and legacy custom work | Fewer boundaries; custom tables and fields use the u_ prefix | Choosing it for new apps to avoid scope settings |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Inherit from the closest-looking table
- What candidates pick
- Extend Incident because the new request records look like incidents.
- Why it looks right
- Incident already has the fields and forms the stakeholder described, so it feels like a shortcut.
- Why it's wrong
- Incident carries ITSM business rules, access controls and process assumptions; Task supplies the shared work fields without them.
Clue to watch for The scenario describes a new, non-IT process that needs assignment, states or SLAs.
-
Hide the module and call it secure
- What candidates pick
- Add a role to the module so only managers can see the data.
- Why it looks right
- The module disappears from the navigator for everyone else, which looks like restricted access.
- Why it's wrong
- Module roles only affect navigation; the table remains reachable by URL, list or API unless access controls restrict it.
Clue to watch for The requirement says users must not be able to view or edit the records, not merely not see a link.
-
Scriptable means good fit
- What candidates pick
- Build a video-transcoding or heavy-calculation tool on the platform because scripts can handle it.
- Why it looks right
- ServiceNow supports server-side JavaScript, so almost anything seems possible.
- Why it's wrong
- Fit is about using built-in strengths: records, workflow, assignment, notifications and reporting. Intensive processing belongs elsewhere, perhaps integrated later.
Clue to watch for The described workload centers on media or computation with no record lifecycle.
-
Wrong-scope mystery
- What candidates pick
- Assume a permissions bug when a new business rule appears under another application.
- Why it looks right
- The symptom looks like a platform error rather than a developer action.
- Why it's wrong
- Files are saved into the current application; if the picker showed another app, the file belongs there.
Clue to watch for The developer switched between applications or worked in the navigator rather than Studio.
-
One reference for many partners
- What candidates pick
- Add a reference field from equipment to group to show which groups can borrow it.
- Why it looks right
- Reference fields are the familiar way to link tables.
- Why it's wrong
- A reference holds one sys_id, so each item could link to only one group; the requirement is many-to-many.
Clue to watch for Both sides are described with 'many' or 'multiple'.
-
New tables are open by default
- What candidates pick
- Assume testers can see records because they have the itil or another general role.
- Why it looks right
- Baseline tables are often readable by broad roles.
- Why it's wrong
- The default table creation can generate a dedicated user role and access controls requiring it, so testers need that role.
Clue to watch for Records exist (an admin can see them) but standard testers see nothing.
Answer framework
When a Domain 1 question asks how to start or structure an application, work through these checks in order.
- Confirm the work is record-based, collaborative and repeatable, with states, assignment or approvals, before choosing to build it on the platform at all.
- Choose the parent table by required behavior: Task for assigned work with states, work notes and SLAs, and no parent for simple reference data.
- Model each relationship by cardinality: a reference field for one-to-many, an intermediate table for many-to-many.
- Select the correct current application, or open the app in ServiceNow Studio, before creating any table, field, module or script.
- Expose the data through an application menu and filtered modules, then rely on access controls, not module roles, to protect it.
Practice question
Want more like this? The ServiceNow CAD practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with the data model, because everything else in this domain hangs from it. In a personal developer instance, create a scoped application, build one table that extends Task and one standalone reference table, then link them with a reference field and add a many-to-many relationship. Open the new records from the Task list to see inheritance and sys_class_name in action.
Next, look at what the platform generated: the user role, the four access controls and the module. Remove the role from a test user and watch the records disappear. Then build two modules, one plain list and one filtered to the current user's open records, to feel the difference between navigation and security.
Candidates underestimate scope. Practice switching the application picker, creating a business rule in the wrong scope, and finding it again. Write a short scoped script that calls gs.log, see it fail, and replace it with gs.info.
Finish with timed practice questions on fit decisions and table design, and for every miss, name the inherited behavior or scope rule you overlooked. Then move to Domain 2, where forms are built on the tables you just designed.
FAQ
How much of the ServiceNow CAD exam is Domain 1?
Designing and Creating an Application is 20% of the exam, one of four domains at that weight. On a 60-question exam that is roughly a dozen questions as a planning estimate, not an official count.
Why does the exam favor extending Task?
Task already carries the fields and behavior that work records need, including number, state, assignment, work notes, approvals and SLA hooks. Extending it reuses that capability without touching the Task table or inheriting another application's logic.
What is the difference between a scoped application and the global scope?
A scoped application has its own namespace and protections, and other scopes must be granted access to its tables and scripts. Global is a shared scope with fewer boundaries, where custom tables and fields use the u_ prefix.
Do I need to memorize every module link type?
Know the common ones and when each fits: List of Records (optionally filtered), New Record, Single Record, Run a Report, URL and Separator. Questions focus on choosing the right type for a navigation need.
Why can a tester not see records in my new table?
Creating a table with the default options can generate a user role and access controls that require it. Until the tester has that role, the access controls deny the records.
Is this domain mostly memorization?
No. Most questions are short design scenarios where several answers would work, and you pick the one that follows best practice by reusing inherited behavior and respecting scope.
How does Domain 1 connect to the rest of the exam?
Forms and scripts in Domain 2 sit on your tables, Domain 3 secures them with access controls and scope, and Domain 6 packages the scoped application for installation and source control.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
You have worked through fit decisions, table extension, relationships, modules and application scope. Check whether you can make those design calls quickly under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ServiceNow CAD AI tutor Get any concept explained your way