Data Model
Tables
New tables are created scoped or global, and either standalone or extending an existing table such astask or cmdb_ci. Extending inherits the parent’s fields and behaviour, which is usually the right choice for anything that behaves like a ticket.
Table properties include the number prefix, icon, auto-numbering, and access settings. Unused custom tables can be deactivated or retired.
Fields
All standard types are available: string, integer, decimal, date and date/time, boolean, reference, choice, glide list, journal, and HTML. Per field you can set:- Mandatory and read-only at the schema level
- Default values
- Maximum length
- Reference qualifiers
- Choice list values, their order, labels, and internal values
Schema-level read-only and mandatory are not the same as a UI policy. Schema settings apply everywhere the field is touched, including imports and scripts. A UI policy applies only to the form. Ask for the one you actually mean.
Relationships
Reference fields, plus reference qualifiers that filter the available choices based on another field or on the current user. One-to-many is a reference field; many-to-many is an intermediate table. Dependent choice lists and related lists follow from these.Users, Roles, and Groups
Attach roles to groups rather than to users wherever the structure allows it. Permissions then follow group membership, which is one change instead of many when someone moves team.
The role model and the workflow are designed together: restricting who may move a record to an approved state is a role decision expressed in the transition.
Classic UI
Form Layout
Which fields appear and in what order, plus sections, tabs, and column breaks. Related lists such as child records, tasks, and approvals are configured here. Multiple form views are supported, so the same table can present differently to different audiences. Self-Service, Admin, and Mobile are the common three.List Layout
List columns, sorting, grouping, and filters, including the default list a role sees. Saved list views cover the recurring cases: “My Team’s Tickets”, “High Priority Only”.UI Policies
Show or hide fields, and make them mandatory or read-only, based on conditions. A worked example: when state is Closed, make Resolution both mandatory and read-only.UI Actions
Buttons on forms and lists, context menu items, and related links. Each carries its own visibility conditions and role restrictions, and runs server-side or client-side logic when clicked. Quick-close and escalate actions are typical.Service Portal
Reusing an existing widget rather than creating a variant is what keeps a portal consistent as it grows.
Workflows and State Machines
Custom status values define the lifecycle, for example New, In Progress, Pending Approval, and Closed. Configuration covers the transitions between them, any guards on those transitions, the initial state, and which transitions are allowed at all. Transitions carry role-based control, so moving a record to an approved state can be limited to managers, and they align with business rules and notifications so that a state change can trigger the rest of the process.Automation and Scripting
Business Rules
Server-side, in four timings: before, after, async, and display. They set or validate fields, enforce logic such as auto-population or preventing an invalid state change, and call script includes for anything reusable.Script Includes
Reusable server-side functions and classes, available to business rules, UI actions, and GlideAjax calls from the client.Client Scripts
Form and list logic running in the browser, in four kinds:
Client scripts reach the server through GlideAjax where they need to.
Scheduled Jobs
Recurring work on a daily, weekly, monthly, or custom interval: maintenance, recalculation, synchronisation, and clean-up.Email Notifications
Triggered by record insert or update, or by a named event. Recipients are users, groups, roles, or resolved dynamically from fields. Subject and body are configurable, including templates, variables, and conditions.Reporting
Standard report types are available: list, bar, pie, line, and others. Each is defined by its group-by, aggregation, time series, and filters, against any table and field combination. Saved list reports are reusable and can be run from modules or dashboards. Reports are embedded into homepages, classic dashboards, or Service Portal pages. Report access is part of the role model. Who may run, edit, or even see a given report is configured alongside it rather than left to default.Designing Across Areas
New applications and modules are defined as a coordinated set: tables, roles, forms, workflows, and portal pages that work together, with naming, security, and UX patterns aligned across them. That coordination is the point. Individually correct components with inconsistent naming and mismatched permissions are how instances become hard to maintain.Your Next Step
Understand what a ServiceNow project is
How the connection works, and what stays in your hands.
See what a Build request sends
What goes out, and what comes back.
Write better requests
How to ask at the right level of detail.
Compare the low-code platforms
What each supported platform covers.