# Best Practices and Exam Review

> Chapter 16 of the Courseiva SERVICENOW-CAD curriculum — https://courseiva.com/learn/servicenow-cad/best-practices-and-exam-review

**Official objective:** 10.1 — Apply platform best practices and review key concepts for the certification exam

## Introduction

Best practices are the set of proven rules and guidelines that help you build ServiceNow applications that are secure, efficient, easy to maintain, and won’t break when someone else touches them. For someone studying the SNOW-CAD exam, understanding these practices is not optional — the exam tests your knowledge of exactly which rules to follow and why, so you can answer questions about naming conventions, security, and update sets correctly.

## The 7-Minute Soup Recipe Analogy

A recipe that takes exactly 7 minutes to follow has 7 steps, each with a specific ingredient and a precise timing. If you add the stock before the vegetables are chopped, or measure the wrong spice, the soup is ruined. In the same way, building an application on the ServiceNow platform without following best practices is like cooking without a recipe: you might get something edible once, but you will never consistently produce a good result, and you will waste time fixing mistakes. 

Think about a professional kitchen. Before a chef starts cooking, they read the entire recipe, gather all ingredients, and understand the final dish. They know that adding salt too early can make vegetables tough, and that stirring too vigorously can break delicate ingredients. In ServiceNow development, the 'recipe' includes the platform’s naming conventions, security rules, update set management, and code modularity. 

If you skip the step of testing a small change in a sub-production instance (like tasting the stock before serving), you risk deploying a bug to production and breaking the whole system. The 7-minute soup recipe forces you to follow a strict sequence: chop, sauté, add liquid, simmer, season, taste, serve. Similarly, the ServiceNow best practice sequence is: plan, develop in a scoped application, test locally, push to update set, test in a separate instance, test in production, and document. When you follow the recipe, the soup always tastes right, and your ServiceNow application always works reliably. That is the whole point of best practices: they give you a repeatable, predictable process so you don't have to reinvent the soup every time.

## Core explanation

Best practices in ServiceNow are the community-agreed ways of doing things that prevent common mistakes, improve performance, and make code easier for other developers to understand. They are not hard rules enforced by the platform (except for a few like mandatory fields on tables), but they are expected by employers and tested on the SNOW-CAD exam. 

The first major area is naming conventions. When you create a new table, field, script, or business rule in ServiceNow, you must give it a name that clearly describes what it does. The platform uses a naming system where applications have a unique prefix (for example, 'u_' for global tables or a custom prefix like 'myapp_'). This prevents naming conflicts between different applications. If you name a field 'color' in one application and another developer names the same field 'color' in a different app, there is no conflict because each field is scoped to its own application. However, on global scopes, prefixes like 'u_' are used to identify custom table and field names so they do not clash with future platform upgrades. The SNOW-CAD exam will test you on when to use the 'u_' prefix versus a custom application prefix. 

Second is update sets. ServiceNow uses update sets to bundle your customisations so they can be moved from one instance to another — for example, from a development instance to a test instance and then to production. A best practice is to always create local update sets for your work, not use the default 'My Updates' set, because when you export a local update set, you get only your stuff. If you use the default set, you risk exporting someone else’s changes or breaking another developer’s work. You should also commit your update set before moving it, which means finalising it so no one else can add random changes while it’s being migrated. The exam will ask you to identify correct update set workflow steps and common errors (like forgetting to commit before export). 

Third is security. ServiceNow has a granular security model with three main layers: Access Control Rules (ACLs), Application Menus (Modules), and User Roles. A best practice is to start with the principle of least privilege: give users only the privileges they absolutely need to do their job, and no more. You implement this by creating roles that contain only the necessary ACLs, and then assigning those roles to users or groups. Never use the 'admin' role for anyone unless they are a system administrator, and never put ACLs directly on a user record. The exam will test you on which ACL type (read, write, create, delete, execute) controls which operation, and how to test ACLs in the platform using the 'High Security Settings' indicator. They also love to ask about the relationship between roles and ACLs: a role is just a name; an ACL uses that name to decide who can perform an action. 

Fourth is performance and maintenance. High-performing ServiceNow applications use forms that load quickly, avoid overloading tables with hundreds of columns, and use indexes on fields that are frequently searched. A best practice is to run the 'Diagnostics' tool on any new table to check for large number of fields or missing indexes. Also, avoid putting business logic (scripts) directly on a ‘Before Insert’ business rule if the same logic can be handled by a ‘current.update()’ or by a separate business rule that runs after the record is saved. The exam will test you on when to use a business rule versus a script include versus a UI policy — and they love to set traps where you confuse script execution order. 

Finally, documentation and code comments are a best practice. Every script should have a comment at the top explaining what it does, who wrote it, and what it expects. This is not just for others — it is also for you six months later. The exam does not directly test documentation comments, but it tests the principle of maintainability, meaning you should build code that another developer (or the system administrator) can easily understand. 

In summary, best practices are the collection of rules that professional ServiceNow developers follow to build applications that are secure, scalable, and maintainable. Without them, you end up with what the community calls 'technical debt' — work that is technically done but hard to change or fix later. The SNOW-CAD exam wants you to recognise the right way to do things so that you can be a competent developer from day one.

## Real-world context

An IT professional called Priya works as a ServiceNow Developer for a mid-size company called GreenTech. GreenTech uses ServiceNow to manage IT support tickets (incidents) and employee requests (service catalogue). Priya is asked to create a custom application called 'Employee Onboarding' that automates the process of setting up new employees with software, hardware, and access permissions. This is a real business need because the company hires 50 people a month and the manual process takes each manager half a day. 

Priya starts by planning. She reads the ServiceNow best practice documentation and decides to follow the recommended approach: use a scoped application (so her changes do not pollute the global namespace), create a local update set named 'Onboarding App v1', and set up a dedicated development instance (a sandbox) for building the application. 

She then creates the main table called 'New Hire' with a prefix 'onboard_' to match her application name 'Onboarding'. She adds fields like name, start date, department, manager, and requested software list. She follows the naming convention: all fields use lower case and underscores, no spaces or special characters. She also adds a reference field to the 'User' table so the new hire record can link to the actual employee in the system. 

Next, she writes a business rule called 'Auto-assign laptop' that runs when a new hire record is created. It checks the department field: if the department is 'Engineering', it triggers a request for a developer laptop; if 'Sales', it requests a standard laptop. She uses a script include (a reusable script snippet) rather than putting the logic directly in the business rule because she might need the same logic elsewhere later. This is a best practice — reuse code rather than duplicate it. 

Third, she configures ACLs. She creates a role called 'hr_manager' and assigns it to the HR team. She then sets ACLs on the 'New Hire' table to allow only users with the 'hr_manager' or 'admin' role to read and write records. She also sets an ACL on the custom script include to ensure only developers with the 'onboarding_app_admin' role can view or modify the script. She tests this by logging in as a regular employee and confirming they cannot see the new hire records. 

Fourth, she creates a custom module (a menu item) under 'My Company' that points to her custom table. She sets its 'Application' scope to 'Onboarding' so it only appears when an HR manager logs in with that role. She also adds a filter condition to show only records where the manager field matches the current user, so managers see only their own new hires. 

Fifth, she tests everything. She first runs a test in the development instance by creating a new hire record, checking the logs to see if the business rule ran, and verifying the ACLs work. Then she commits her update set (finalises it) and moves it to a separate test instance. There, another developer tests it. Only after it passes testing does Priya move the update set to production. 

Finally, after deployment, she monitors the performance: the form loads fast, the ACLs are working, and there are no error logs. She documents everything in a Knowledge Base article for the next developer. This real-world scenario shows that following best practices prevents bugs, saves time, and makes the application easy to maintain. Without them, Priya might have accidentally exposed sensitive employee data, caused performance issues, or broken other parts of the system.

## Exam focus

The SNOW-CAD exam tests 'Best Practices and Exam Review' in several specific ways. First, they will ask you direct multiple-choice questions about naming conventions: for example, 'What prefix should you use for a custom field on a global table?' The correct answer is 'u_' (because global tables use the 'u_' prefix to indicate custom fields). They also ask about scoped applications: which prefix you should use for a table defined in a scoped application? The answer is not 'u_' but the application’s own prefix (like 'myapp_'). A common trap is that they show a field called 'u_color' and ask if that is correct for a scoped application — the answer is no, because in a scoped application you use the application prefix. 

Second, update set questions are very common. They might present a scenario like: 'A developer created a business rule but did not commit the update set. What happens when they try to export it?' The answer is: the update set cannot be exported until it is committed. They also test the order of operations: first, create the local update set; second, set it as the current update set; third, make your changes; fourth, commit; fifth, export. They often reverse the order in the choices to confuse you. 

Third, security is a big topic. They test ACLs heavily, especially the difference between read, write, create, delete, and execute ACLs. They love to give a scenario where a user has a role that grants read access to a table but the record-level ACL says the user cannot read a specific record — and they ask which one wins. The answer is: record-level ACLs override table-level ACLs because they are more specific. They also test the concept of 'without condition' versus 'with condition' on ACLs. A common trap is a question like: 'A role has read access to the incident table, but the user cannot see the incident form. What is the most likely cause?' The answer is a record-level ACL with a condition that blocks the user, or the user does not have the required role to access the form module. 

Fourth, they test the concept of scoped applications versus global scope. A scoped application is a separate namespace where you can build custom applications without affecting the global namespace. They will ask: 'What is the advantage of using a scoped application?' The correct answer is: it prevents naming collisions and allows the application to be moved between instances more easily. They also test that scripts in a scoped application cannot directly call global scripts unless you use a specific API (like GlideRecord). 

Fifth, they test best practices for performance: they ask about indexing, the number of fields on a form (keep it under 20–30), and using script includes to avoid code duplication. A classic question: 'A developer writes the same 10-line script in 5 different business rules. Which best practice is violated?' The answer is: reusability — they should have created a script include. 

Key definitions to memorise: update set (a container for changes), commit (finalising an update set), local update set (yours only), scoped application (isolated namespace), ACL (Access Control Rule), role (a collection of privileges), naming convention (systems for prefixes), script include (reusable script), and business rule (server-side logic). The exam expects you to know these cold. 

Traps to watch out for: 
- Confusing 'u_' prefix (global) with application prefix (scoped). 
- Thinking you can export an update set without committing it. 
- Believing that a role alone grants access to a form — it does not; you also need a module (menu item) with the correct role. 
- Mixing up read ACLs and write ACLs — a user can read a record but not edit it if only read ACL exists. 
- Assuming that if you have the admin role you can bypass all rules — not true for some system properties like high-security settings. 

Study these patterns: memorize the update set life cycle: create -> make current -> make changes -> commit -> export -> import -> install. Know the three layers of security: module, table, record. Know the difference between ACLs without condition (applies to all records in table) and with condition (applies only to matching records). The exam will give you a scenario and ask you to choose the correct sequence or identify the error.

## Step by step

1. **Plan the Application** — Read the requirements, identify the main table, fields, and business rules needed. Choose a unique application prefix (e.g., 'onboard_') for your scoped application. This step prevents you from later needing to rename things or fix conflicts.
2. **Set Up the Scoped Application** — In ServiceNow, create a new application under 'Application Creator'. Set the scope to 'Application' (not global). Define your application prefix. This isolates your work from other applications and makes it portable.
3. **Create a Local Update Set** — Go to 'Update Sets' and click 'New'. Give it a descriptive name like 'Onboarding App v1'. Set it as the current update set. Every change you make from now on will be captured in this update set, which you can later export.
4. **Build the Tables and Fields** — Create your custom table using the application prefix (e.g., 'onboard_new_hire'). Add fields carefully: use specific data types (string, integer, date, reference). Set mandatory fields where needed. Follow naming conventions: lowercase with underscores.
5. **Configure Business Rules and Script Includes** — Write any server-side logic as a script include for reusability. Then create a business rule that calls that script include. This keeps your code clean and modular. Test the business rule in the development instance by creating a record and checking logs.
6. **Set Up Security (Roles and ACLs)** — Create a role (e.g., 'hr_manager') in the 'Roles' table. Then create ACLs for each operation (read, write, create, delete) on your custom table, requiring that role. Also add a record-level condition if needed. Test by logging in as a user without the role.
7. **Create Modules and User Interface** — Create a module (menu item) under a suitable application module (e.g., 'My Company'). Set the role requirement on the module. Configure the form layout (form view) to show relevant fields only. Test that the menu appears only for users with the correct role.
8. **Commit and Export the Update Set** — After all changes are tested, go to 'Update Sets', locate your update set, and click 'Commit'. This finalises it. Then click 'Export to XML'. You now have a portable file that can be moved to another instance.
9. **Deploy and Monitor in Production** — Import the update set into the production instance via 'Retrieved Update Sets'. Preview the changes, then commit and install. After deployment, monitor logs for errors and confirm that ACLs and business rules work as expected.

## Comparisons

### Global Scope vs Scoped Application

**Global Scope:**
- Uses the 'u_' prefix for custom tables and fields
- No namespace isolation; can conflict with other global customisations
- Cannot be moved easily between instances because it relies on global system objects

**Scoped Application:**
- Uses the application’s own prefix (e.g., 'onboard_')
- Fully isolated namespace; no conflicts with other apps
- Portable — can be exported and installed on any instance as a complete package

### Default Update Set vs Local Update Set

**Default Update Set:**
- Shared across all developers in the instance
- Cannot be renamed or easily identified for a specific task
- Makes rollback very hard because changes are mixed

**Local Update Set:**
- Created per task or feature
- Can be named descriptively and exported separately
- Easier to roll back by simply uninstalling the update set

### Table-level ACL vs Record-level ACL

**Table-level ACL:**
- Applies to all records in a table
- Requires only a role condition (no condition script needed)
- If a user has no read ACL on the table, they cannot see any records

**Record-level ACL:**
- Applies only to records that match a condition (e.g., state = open)
- Must have a table-level ACL first (to allow access), then a record-level ACL to restrict further
- More specific: overrides table-level ACL for matching records

### Business Rule (Direct Script) vs Script Include

**Business Rule (Direct Script):**
- Script is written directly inside the business rule form
- Cannot be reused in other business rules or script actions
- Harder to maintain because changes need to be made in multiple places

**Script Include:**
- Script is stored in a separate reusable object
- Can be called from multiple business rules, UI actions, and scheduled jobs
- Easier to test and debug because it is isolated

## Diagram

_This flowchart shows the recommended step-by-step process for building a ServiceNow application from planning to production deployment, following best practices for update sets, scoping, and security._

```mermaid
flowchart TD
    A[Start: Plan Application] --> B[Create Scoped Application]
    B --> C[Create Local Update Set]
    C --> D[Design Table and Fields]
    D --> E[Add Business Rules and Script Includes]
    E --> F[Set Up ACLs and Roles]
    F --> G[Create Modules and Form Views]
    G --> H[Test in Dev Instance]
    H --> I{Passes Testing?}
    I -->|Yes| J[Commit Update Set]
    I -->|No| C
    J --> K[Export Update Set]
    K --> L[Import into Test Instance]
    L --> M[Test in Test Instance]
    M --> N{Passes?}
    N -->|Yes| O[Deploy to Production]
    N -->|No| C
    O --> P[Monitor and Document]
```

## Common misconceptions

- **Misconception:** I should always use the default 'My Updates' update set because it is easier than creating a new one. **Reality:** You should always create a new local update set for each task or feature, because the default set mixes everyone's changes and makes export and rollback nearly impossible. (Beginners usually work alone in a sandbox and never experience conflicts, so they underestimate the chaos that occurs when multiple developers use the same default update set in a real environment.)
- **Misconception:** Using the 'admin' role is fine for testing because it gives me full access and I can see everything works. **Reality:** You should never use the admin role for development or testing; always use a custom role with the least privileges needed, so you can test ACLs and security properly from a user's perspective. (Admin bypasses all ACLs, so you will never catch security mistakes until production, where a real user gets access they should not have.)
- **Misconception:** If I name my table 'u_employee_data', it is fine for any application because 'u_' means custom. **Reality:** The 'u_' prefix is only correct for global tables. For tables inside a scoped application, you must use the application's own prefix (like 'myapp_employee_data'). (Many beginners do not understand the difference between global and scoped namespaces, and the exam uses this confusion to set traps.)
- **Misconception:** ACLs are optional; I can just set the module to 'public' to let everyone see the form. **Reality:** ACLs are mandatory for security. Setting a module to 'public' only controls menu visibility — it does not control record-level access, and anyone could still see data via a direct URL if ACLs are missing. (People confuse the module (menu) with the underlying data access. The exam tests this exact confusion.)
- **Misconception:** Once I export an update set, I can edit it again and re-export without committing. **Reality:** No — once an update set is exported, you cannot commit or modify it again. You must commit before export, or create a new update set for any additional changes. (The platform locks exported update sets to prevent corruption, but beginners expect to be able to 'undo' or 'add more' after export, which is not how it works.)

## Key takeaways

- Always create a new local update set before making changes, and commit it before export.
- Use the 'u_' prefix for custom fields and tables on global scope, and the application prefix for scoped applications.
- Apply the principle of least privilege: assign users only the roles and ACLs they need to do their job.
- Write reusable code using script includes rather than duplicating logic across multiple business rules.
- Test ACLs by logging in as a user without the admin role to ensure security works as intended.
- Avoid using the admin role for development because admin bypasses all ACLs and hides security gaps.
- Document your code with comments and maintain a knowledge base article for each custom application.
- Keep forms simple — add only necessary fields and create indexes on frequently searched columns.
- A role does not grant access to a module; you must configure the module to require that role.
- Record-level ACLs override table-level ACLs because they are more specific.

## FAQ

**What does 'u_' mean in ServiceNow field names?**

The 'u_' prefix stands for 'user' or 'custom'. It is used for custom fields and tables created on the global scope to distinguish them from out-of-box platform fields.

**Can I edit an update set after I export it?**

No. Once an update set is exported, it is locked and cannot be edited. You must create a new update set for any additional changes.

**What is the difference between a scoped application and a global application?**

A scoped application has its own namespace (prefix), so it cannot accidentally interfere with other applications. A global application shares the global namespace and must use the 'u_' prefix for customisations.

**Do I have to use roles for ACLs?**

Yes — ACLs require a role (or condition) to determine who can perform an action. You cannot have an ACL without at least one role attached to it.

**What happens if I forget to commit my update set before export?**

The system will not allow you to export it. You must commit first, which finalises the set and prevents further changes.

**Why should I avoid using the admin role for development?**

Because the admin role bypasses all ACLs and security checks, so you cannot test whether a normal user can access the data correctly. This can lead to security gaps in production.

**How many fields is too many for a ServiceNow form?**

A best practice is to keep forms to 20–30 fields maximum. More than that can slow down form loading and confuse users. Use sections or tabs to organise.

## Check your understanding

1. **What prefix should you use for a custom field on a global table, and why?**

   Answer: You should use 'u_' prefix because it identifies the field as custom and prevents naming conflicts with future platform upgrades.

2. **What is the first step you should take before making any changes in a ServiceNow instance?**

   Answer: First, create a local update set and set it as the current update set so that all your changes are captured for later export.

3. **If you have a table-level read ACL that allows 'sales_rep' role access, but a record-level read ACL blocks that same role for records with status='Closed', which ACL wins?**

   Answer: The record-level ACL wins because it is more specific and overrides the table-level ACL for matching records.

4. **Why should you avoid using the admin role when developing a new application?**

   Answer: Because the admin role bypasses all ACLs, so you cannot properly test whether security rules allow or block appropriate users.

5. **What is the recommended way to reuse a piece of server-side logic across multiple business rules?**

   Answer: Create a script include that contains the logic, then call that script include from each business rule. This ensures reusability and easier maintenance.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-cad/best-practices-and-exam-review