ServiceNow CAD cheat sheet

A scoped application stores its artifacts under a unique namespace prefix (for example x_acme_orders); its tables, scripts, roles, and properties are isolated from other scopes.

The application scope is chosen when the application is created and cannot be changed afterward, so scope selection is a one-time design decision.

Custom tables created in the global scope use the u_ prefix; the sys_ prefix is reserved for base-system tables delivered by the platform.

Update sets store configuration changes as XML records in sys_update_xml, grouped by a parent record in sys_update_set.

Typical instance landscape: development, then test/staging, then production; sub-production instances are usually created by cloning production.

A role (sys_user_role) grants permissions; roles reach users directly through sys_user_has_role or indirectly through group membership.

Recommended design sequence: personas and process, then data model, then forms and lists, then logic, then security, then deployment.

Flow Designer automates processes with triggers, actions, and flows, and is the platform's current tool for new process automation.

Every table has a parent chain rooted at sys_db_object, and every record carries a 32-character sys_id as its primary key.

Table extension: a child table inherits all parent fields, each row is stored once in the child table, and a query on the parent returns rows from parent and children.

Table metadata lives in sys_db_object; field metadata (type, length, reference, default) lives in sys_dictionary.

A reference field stores the sys_id of a record on another table and forms a one-to-many relationship; dot-walking (current.assigned_to.email) reads fields through it.

A choice field stores the value while displaying the label; the pairs are defined on the dictionary or as records in sys_choice.

One-to-many uses a reference field on the many side; many-to-many uses an m2m table with two reference fields, such as sys_user_grmember linking users and groups.

incident, problem, change_request, and sc_task all extend the task table, so task-level fields and business rules apply to each of them.

sys_user_has_role stores role grants to users and groups; sys_user_grmember links user records to group records.

Create a database index (sys_index) on columns that appear frequently in query conditions to reduce full table scans.

Number maintenance (sys_number) defines the prefix and counter that produce identifiers such as INC0010001.

UI policies run on the client and set fields mandatory, visible, or read-only; the Run scripts option enables script actions and Reverse if false restores the original state when the condition stops matching.

Data policies enforce mandatory and read-only on the server, so the rule applies to imports, web services, and mobile clients as well as forms.

Client script types are onLoad, onChange, onSubmit, and onCellEdit; all of them use the g_form API rather than direct DOM access.

g_form methods include setValue, getValue, setVisible, setMandatory, setReadOnly, addOption, clearValue, showFieldMsg, and save.

onCellEdit fires when a cell is edited directly in a list; onSubmit can block a save by returning false.

Form views (sys_ui_view) present different layouts of the same table to different audiences; the default view is used when no view is specified.

A dictionary override changes a field's behavior (for example mandatory or default value) for one child table without affecting the parent.

Related lists on a form are defined in sys_ui_related_list, and list columns are defined in sys_ui_list.

The Order field on a UI policy determines execution sequence when several UI policies target the same form.

Business rule types: before (modifies current in memory, no extra write), after (needs current.update() to persist changes), async (runs in a background job after the transaction), display (runs when a record is loaded for display).

A before business rule can assign current.field values directly and they save with the transaction; calling update() in an after rule risks recursion and should be guarded with setWorkflow(false).

GlideRecord pattern: addQuery or addEncodedQuery, then query(), then while (next()) with getValue and setValue, then update(), insert(), or deleteRecord().

GlideAggregate performs count, sum, average, min, max, and groupBy in the database and is preferred over looping GlideRecord rows.

GlideAjax calls a client-callable script include (extending AbstractAjaxProcessor) so a client script can run server-side logic.

Client scripts cannot use GlideRecord; available objects are g_form, g_user, g_list, and GlideAjax.

On-demand script includes run only when explicitly called; client-callable script includes must have the Client callable flag set.

gs utility methods include gs.info, gs.log, gs.getUserID, gs.hasRole, gs.addInfoMessage, and gs.nowDateTime.

Scheduled jobs and Flow Designer actions run server-side on a schedule or a record trigger, independent of any user session.

ACL types are record, field, client_callable_script_include, rest_endpoint, ui_page, and processor; operations are read, write, create, delete, and execute.

If no ACL matches a table or field, access is allowed by default; ACLs restrict, they do not grant by default.

Admins bypass ACL checks by default; clearing the Admin overrides option on an ACL makes that rule apply to admins as well.

An ACL script sets answer to true or false and can call gs.hasRole(), gs.getUserID(), and inspect the current record.

For a field read or write to succeed, any field ACL and the matching table ACL must both allow the operation.

Roles are defined in sys_user_role, can contain other roles through sys_user_role_contains, and can be granted to groups through sys_group_has_role.

A scoped application needs a cross-scope privilege (sys_scope_privilege) to read or call artifacts that belong to another scope.

A client-callable script include requires a client_callable_script_include ACL before a browser script can invoke it.

Creating or editing ACLs requires elevating to the security_admin role for the current session.

Update sets capture global-scope configuration; lifecycle is create, make changes, complete, export or retrieve, preview, commit, with back-out available to revert.

Preview reports collisions and errors before commit; updates whose parent records are missing are skipped and must be resolved manually.

Scoped applications deploy as versions through the Application Repository rather than through update sets.

Cloning copies production to a sub-production instance; clone profiles control excluded tables, preserved data, and anonymization.

Import set flow: data source, staging table (sys_import_set_row), transform map, target table; coalesce fields decide update versus insert.

A transform map can define field maps, source scripts, and onBefore and onAfter scripts; coalesce fields should uniquely identify the target record.

Outbound integrations use REST or SOAP messages; inbound integrations use Scripted REST APIs or import sets; a MID Server reaches systems on a customer network.

After a platform upgrade, skipped records appear in the upgrade history and must be reviewed and resolved manually.

IntegrationHub spokes and actions extend Flow Designer to third-party systems without custom scripted integration code.