Code Review in ServiceNow

Code Review in ServiceNow: A Comprehensive Guide for CAD Exam Preparation

Code Review in ServiceNow

Why is Code Review Important?

Code review is a critical practice in ServiceNow development that ensures the quality, security, maintainability, and performance of customizations and applications built on the platform. In enterprise environments, where ServiceNow instances serve as the backbone of IT operations, a single poorly written script can cause performance degradation, security vulnerabilities, or system instability. Code review acts as a quality gate that helps organizations:

- Maintain platform health: Poorly written scripts can slow down the entire instance, affecting all users and integrations.
- Ensure security compliance: Unreviewed code may introduce injection vulnerabilities, expose sensitive data, or bypass access controls.
- Promote best practices: Code reviews enforce consistent coding standards across development teams.
- Reduce technical debt: Catching issues early prevents costly rework and maintenance challenges later.
- Facilitate knowledge sharing: Reviewing each other's code helps team members learn and grow their ServiceNow development skills.

What is Code Review in ServiceNow?

Code review in ServiceNow refers to the systematic examination of scripts, configurations, and customizations before they are promoted to production environments. ServiceNow provides built-in tools and processes to facilitate code review as part of the application development lifecycle.

Key components include:

1. Automated Code Review (Instance Scan)
ServiceNow offers Instance Scan, a built-in tool that automatically scans your instance for code quality issues, performance problems, and deviations from best practices. Instance Scan checks for common issues such as:
- GlideRecord queries without proper filters
- Use of synchronous AJAX calls (gr.query() in client scripts)
- Direct DOM manipulation
- Hardcoded sys_ids
- Missing null checks
- Inefficient queries in loops

2. Code Review in Source Control (Update Sets and Scoped Applications)
When using source control integration (e.g., with Git through ServiceNow Studio or the Source Control Integration app), developers can implement peer code review processes similar to pull requests. This allows team members to review changes before they are merged into the main branch.

3. Manual Peer Review
This involves developers reviewing each other's scripts, business rules, client scripts, UI actions, script includes, and other artifacts to ensure they meet organizational coding standards.

4. Automated Testing Framework (ATF)
While not strictly a code review tool, ATF supports the review process by validating that code changes work as expected and do not introduce regressions.

How Does Code Review Work in ServiceNow?

Step 1: Development in a Scoped Application or Update Set
Developers create their customizations within a scoped application or update set. This isolates changes and makes them reviewable as a cohesive unit.

Step 2: Running Instance Scan
Before submitting code for peer review, developers should run Instance Scan against their changes. Navigate to Instance Scan > Scan Instances to execute a scan. The scan produces a report highlighting issues categorized by severity (critical, high, medium, low). Developers should address critical and high-severity findings before proceeding.

Step 3: Peer Review Process
The code is then submitted for peer review. In organizations using source control, this typically involves creating a branch, pushing changes, and opening a review request. Reviewers examine:
- Script quality: Is the code well-structured, readable, and following naming conventions?
- Performance: Are GlideRecord queries optimized? Are there unnecessary database calls?
- Security: Does the code properly handle user input? Are ACLs respected?
- Best practices: Does the code follow ServiceNow best practices (e.g., using GlideAjax for client-server communication instead of GlideRecord on the client side)?
- Scope and impact: Does the change affect other parts of the system unintentionally?

Step 4: Addressing Feedback
Developers address review comments, make corrections, and resubmit for review if necessary.

Step 5: Approval and Promotion
Once the code passes review, it is approved and promoted through the deployment pipeline (e.g., from development to test to production).

Key Best Practices for Code Review in ServiceNow

- Never use GlideRecord in client scripts: Use GlideAjax to call server-side Script Includes instead.
- Avoid hardcoded sys_ids: Use system properties or reference qualifiers instead.
- Use proper scoping: Develop within scoped applications to maintain modularity and prevent conflicts.
- Limit the use of global scope: Only use global scope when absolutely necessary.
- Optimize GlideRecord queries: Always add appropriate filters, use setLimit() when only one record is needed, and avoid querying inside loops.
- Follow the principle of least privilege: Ensure scripts only access what they need.
- Use descriptive variable names and comments: Make code readable for future reviewers and maintainers.
- Test before review: Use ATF to validate functionality before submitting for review.
- Check for cross-scope access: Ensure that scoped applications properly declare and manage cross-scope privileges.

Common Code Review Findings in ServiceNow

Performance Issues:
- GlideRecord queries without query conditions (selecting all records)
- Nested GlideRecord queries (queries within loops)
- Not using setLimit() when only checking for record existence
- Using getRowCount() instead of hasNext() to check for records

Security Issues:
- Executing scripts with elevated privileges unnecessarily
- Not validating user input in processors or scripted REST APIs
- Exposing sensitive fields through client-accessible scripts

Maintainability Issues:
- Duplicated code that should be consolidated into Script Includes
- Lack of error handling and logging
- Overly complex scripts that should be broken into smaller functions

Exam Tips: Answering Questions on Code Review in ServiceNow

1. Know the Purpose of Instance Scan: The exam may ask about ServiceNow's built-in tools for code quality. Remember that Instance Scan is the primary automated tool for identifying code quality and best practice violations. Understand what it checks for and how to use it.

2. Understand Client-Side vs. Server-Side Best Practices: A very common exam topic is knowing that GlideRecord should never be used in client scripts. The correct approach is to use GlideAjax to communicate with a server-side Script Include. If a question asks about the best way to retrieve server data from a client script, always choose GlideAjax.

3. Know What to Look for in Code Reviews: Exam questions may present code snippets and ask you to identify issues. Look for:
- Hardcoded sys_ids (bad practice)
- GlideRecord on the client side (bad practice)
- Queries without filters (performance issue)
- Queries inside loops (performance issue)
- Missing error handling

4. Understand the Role of Source Control: Know that ServiceNow supports integration with Git repositories for version control and that this facilitates code review through branch-based workflows. The exam may reference Studio and its source control capabilities.

5. Remember the Update Set Review Process: When update sets are moved between instances, they go through a review and commit process. Understand that this is a checkpoint where code and configuration changes should be reviewed before being committed to the target instance.

6. Associate Code Review with the SDLC: The exam may ask where code review fits in the software development lifecycle. Code review occurs after development and before deployment to higher environments. It is a key part of the quality assurance process.

7. Familiarize Yourself with Scoped Application Best Practices: Questions may test your understanding of how scoped applications promote better code management. Scoped applications provide isolation, making code review more manageable because changes are contained within a defined scope.

8. Watch for Trick Answers: Some exam questions may present answers that sound reasonable but violate best practices. For example, an answer suggesting the use of current.update() inside a before business rule is incorrect because the system automatically saves the record after a before business rule — calling update() would trigger an additional, unnecessary database operation.

9. Understand the Collaboration Tools: Know that ServiceNow provides Team Development capabilities that support collaborative development and code review across multiple developers working on the same instance or across instances.

10. Practice with Scenario-Based Questions: Many CAD exam questions are scenario-based. When you encounter a scenario about code quality or review, think about:
- What is the most efficient approach?
- What follows ServiceNow best practices?
- What minimizes performance impact?
- What is the most maintainable solution?

By understanding these principles and practicing with real-world scenarios, you will be well-prepared to answer code review questions on the ServiceNow Certified Application Developer (CAD) exam.