Description

ServiceNow Tables and Forms Development & configurations

In ServiceNow, Tables are the database foundation where all records (like Incidents or Users) are stored, while Forms are the user interface (UI) used to interact with those records.

1. Table Development & Configuration

Everything in ServiceNow is a table. When you develop a table, you are defining the data schema for your application.

Table Types

1. Base Tables: Standalone tables that do not inherit from any other (e.g., task or cmdb_ci).
2. Extended Tables: Tables that inherit fields and logic from a parent. For example, incident extends task. This is a best practice to reuse common fields like “Short Description” or “State.”
3. Custom Tables: Tables created by developers (prefixed with u_ in Global scope or x_ in Scoped apps).

Key Configurations

1. Dictionary Entries: Every column in a table is a dictionary entry. Here you define the Field Type (String, Reference, Choice, etc.), Max Length, and Default Values.
2. Reference Fields: These create relationships between tables. A “Caller” field on an incident is a reference to the sys_user table.
3. Extensibility: You can mark a table as Extensible so other developers can build on top of it.

2. Form Development & Design

Forms are the visual representation of a single record. ServiceNow provides three primary tools to build them:

3. Adding Logic to Forms (Form Behavior)

To make forms “smart” (e.g., hiding a field until a checkbox is clicked), you use two main client-side tools:

1. UI Policies (No-Code): The preferred way to set fields to Mandatory, Read-only, or Visible based on conditions. They are easy to maintain and execute after scripts.
2. Client Scripts (Pro-Code): Used for complex logic that UI Policies can’t handle, such as displaying alerts, validating input formatting via Regex, or changing values dynamically using g_form.
3. Types: onLoad, onChange, onSubmit, and onCellEdit.

4. Development Best Practices

1. Inherit from Task: If your table involves work (assignments, states, SLAs), always extend the task table to save development time.
2. UI Policy Over Client Script: Always use a UI Policy if possible. It is more performant and easier for other admins to debug.
3. Avoid Duplicate Fields: Do not place the same field in multiple sections of a form. This causes “rendering conflicts” where the system doesn’t know which value to save.
4. Field Lengths: Be intentional with string lengths (e.g., 40, 100, 4000). Changing length later can be difficult depending on the database backend.

Would you like to see a comparison of when to use a Business Rule (server-side) versus a Client Script (client-side)?

ServiceNow Form Design vs. Form Layout

This video provides a visual walkthrough of the different form-building tools available to help you choose the right one for your configuration needs.