Description

ServiceNow Custom Application Development & Configurations

This guide provides a structured overview of the custom application development lifecycle, the core components, and critical configuration best practices within the ServiceNow platform.

1. The Custom Application Development Lifecycle (Agile Approach)

The development process on ServiceNow generally follows an Agile/iterative approach, focusing on delivering value quickly and gathering continuous feedback.

2. Core Building Blocks (The “What” to Configure)

Every custom application is built from a collection of interconnected ServiceNow components.

2.1. Data Layer (Tables)

1. Tables: The fundamental structure for storing data.
2. Best Practice: Always extend a base table (e.g., task, cmdb_ci) if the custom table shares common characteristics, ensuring inheritance of standard fields and platform functionality (e.g., approvals, SLAs).
3. Fields: Use the most appropriate data type (e.g., Reference fields for linking to other tables, Choice lists for defined options).

2.2. User Interface (Forms, Lists, Portals)

1. Forms: The view for single records. Configured using Form Designer or Form Layout.
2. Configuration: Use UI Policies (low-code) and Client Scripts (pro-code) to control visibility and behavior (e.g., making a field mandatory based on another field’s value).
3. Lists: Display multiple records. Configured using List Layout.
4. Experiences:
5. Now Experience UI Builder: Low-code tool for building modern, mobile-responsive workspaces and portals.
6. Service Portal: (Legacy) For building customer/employee-facing self-service portals using Widgets (HTML, CSS, Angular/Server Script).

2.3. Business Logic & Automation (Scripting & Flows)

1. Business Rules (Server-side): Execute logic on the server (before/after database actions).
2. Configuration: Must be scoped to the application. Use sparingly and efficiently.
3. Script Includes (Server-side): Reusable JavaScript functions, often called from Business Rules, Workflows, or Client Scripts (via GlideAjax).
4. Best Practice: Centralize complex business logic here to promote reusability and maintainability.
5. Flow Designer / Workflows: Automate multi-step business processes. Flow Designer is the preferred modern tool.
6. Configuration: Used for approvals, task creation, notifications, and integrations (using IntegrationHub).

2.4. Security (Access Control)

1. Roles: Define the user’s function and permissions. Custom applications should always define their own specific roles (e.g., x_app_manager, x_app_user).
2. Access Control Lists (ACLs): Define what data a user can access (read, write, create, delete) and under what conditions.
3. Best Practice: Define security at the most restrictive level (Table > Field, Row > Column) and then grant permissions.

3. Essential Configuration Best Practices

3.1. Scoped Application Development (Mandatory)

1. Scope: Always develop in a Scoped Application. This provides a unique namespace (e.g., x_12345_myapp), preventing naming collisions and protecting your application’s components from external changes, greatly simplifying future upgrades.
2. System Properties: Use System Properties (sys_properties) to store configuration values (like API keys, threshold limits, or default user IDs) instead of hardcoding them in scripts.

3.2. Performance & Efficiency

1. Avoid Client-side Code: Minimize the use of Client Scripts as they impact form load time. Prefer UI Policies or server-side alternatives where possible.
2. Efficient GlideRecord: When scripting:
3. Avoid using addQuery() on non-indexed fields.
4. Use get(sys_id) for single record retrieval.
5. Avoid complex queries or unnecessary lookups inside loops.
6. Asynchronous Operations: Use Asynchronous Business Rules or Flow Designer to handle long-running or non-critical processes to prevent users from waiting.

3.3. Deployment & Migration

1. Use the Application Repository: For moving scoped applications between instances (Dev to Test to Prod), always publish the application to the Application Repository. This provides version control and simplifies the deployment process compared to using Update Sets.
2. Update Sets: Only use Update Sets for records that reside outside the application scope, such as:
3. New users or groups.
4. Modifications to global records (e.g., global UI Scripts).
5. Data records (if not handled by Fix Scripts).

3.4. Code Quality

1. Instance Scan: Run the Instance Scan tool regularly to identify common development issues, performance bottlenecks, and adherence to best practices.
2. Comments & Documentation: Document all scripts (Client Scripts, Business Rules, Script Includes) clearly, explaining the why (purpose) and how (logic) of the code.

Summary of Key Configurations