Database Management & Platform Security

Everything in ServiceNow is stored in tables. Understanding the table structure and dictionary is fundamental to administration.

Core Table Concepts

• Tables are stored in the sys_db_object table.
• Fields (columns) are defined in the Dictionary [sys_dictionary].
• Every record has a sys_id — a unique 32-character GUID primary key.
• Table inheritance — child tables extend parent tables and inherit all fields.
• Application scope determines which application owns a table.

Common Field Types

ACLs (Access Control Rules) are the primary security mechanism in ServiceNow. They control who can read, write, create, and delete records at the table, field, and row level.

ACL Evaluation Order

1. Field-level ACL on the specific table (most specific).
2. Field-level ACL on a parent table.
3. Table-level ACL on the specific table.
4. Table-level ACL on a parent table.
5. Global default (wildcard * ACL).

ACL Rule Structure

• Operation — read, write, create, delete.
• Name — table.field (e.g., incident.priority, incident.*, *).
• Condition — Filter conditions the record must match.
• Role — Roles required (can require one or more).
• Script — Advanced conditions evaluated with JavaScript.
• ALL matching ACLs must evaluate to true for access to be granted.

UI Policies dynamically change form behavior based on field values. They run CLIENT-SIDE and control field visibility, mandatory status, and read-only status.

UI Policy Capabilities

• Make a field mandatory (required).
• Make a field read-only (non-editable).
• Show/hide a field on the form.
• Set a field value when conditions are met.
• Can be configured to reverse the action when conditions are no longer met.
• Runs on form load and onChange events.

UI Policy Configuration

• Table — Which table the policy applies to.
• Conditions — When the policy activates (e.g., Priority = 1).
• UI Policy Actions — What happens (set mandatory, read-only, visible, or value).
• Reverse if false — Whether to undo the action when conditions no longer match.
• Inherit — Whether child tables also get this policy.
• Order — Execution order (lower numbers run first).

Data Policies enforce data quality rules on the SERVER SIDE. Unlike UI Policies, they cannot be bypassed by APIs, import sets, or scripts.

Data Policy vs. UI Policy

Business Rules are server-side scripts that run when records are inserted, updated, deleted, or queried. They are one of the most powerful configuration tools and heavily tested on the exam.

Business Rule Types (When)

Key Business Rule Objects

• current — The record being processed.
• previous — The record's values BEFORE the update (only in update operations).
• current.operation() — Returns 'insert', 'update', or 'delete'.
• current.setAbortAction(true) — Cancels the database operation (before rules only).
• gs.addInfoMessage() / gs.addErrorMessage() — Display messages to the user.

Client Scripts run in the user's browser (client-side) and control form behavior, field validation, and user interactions. They use the GlideForm (g_form) API.

Client Script Types

Key Client-Side APIs

• g_form — GlideForm API: getValue, setValue, setMandatory, setVisible, setReadOnly, addInfoMessage.
• g_user — GlideUser API: userName, userID, hasRole, hasRoleExactly.
• g_list — GlideList API: for list manipulation (rarely tested).
• GlideAjax — Make asynchronous server calls from client scripts.

Understanding when each type of server-side and client-side logic runs is CRITICAL for the CSA exam. Many questions test whether you know the correct execution order.

Client-Side Execution Order (Form Load)

1. Client Scripts (onLoad) — Runs first when the form loads.
2. UI Policies — Evaluate after onLoad scripts. Set field visibility, mandatory, read-only.
3. Display Business Rules — Provide additional data/messages to the form.

Client-Side Execution Order (Field Change)

1. Client Scripts (onChange) — Fires when a field value changes.
2. UI Policies — Re-evaluate conditions based on the new field value.

Server-Side Execution Order (Record Save)

1. Client Scripts (onSubmit) — Validate and potentially cancel the save.
2. Before Business Rules — Server-side validation and data modification.
3. Database operation — Record is inserted/updated/deleted.
4. After Business Rules — Trigger side effects after the save.
5. Async Business Rules — Run in background after the transaction commits.

Security is woven throughout the platform. Beyond ACLs and roles, there are several security features tested on the exam.

Security Features

• High Security Settings — Plugin that enables additional security features (IP restrictions, password policies, session management).
• Contextual Security — ACLs that evaluate based on the context of the request (who, what, where).
• Encryption — Field-level encryption for sensitive data (SSN, credit card numbers).
• IP Access Controls — Restrict access based on IP addresses/ranges.
• Multi-Factor Authentication (MFA) — Additional authentication layer.
• Security Incident Response — Track and manage security events.

Principle of Least Privilege

Always assign the minimum roles and access necessary. Avoid granting the admin role broadly. Create custom roles that contain only the specific permissions needed.