› CIS-DF Hub › Part 6 › Reference Qualifiers & Field Security
⬡ Part 6 · Topic 3

Reference Qualifiers & Field Security

Reference Qualifiers filter which records appear in reference field pickers. Field-level ACLs control which users can see or write specific fields. Together, they enforce data quality and security at the field level.

📋 5 sections ⏱ ~18 min read 🎯 ~8% exam weight 🏷 Data Quality
Section 1

Reference Qualifiers

When a Reference field points to a table (like assigned_to pointing to sys_user), by default the picker shows every active record in that table. For a table with 10,000 users, that's unwieldy. A Reference Qualifier filters what appears in the picker, narrowing the options to only relevant records.

For example: the Assignment Group field on Incident could be qualified to only show groups with the "Assignment Group" type flag set. Without the qualifier, every group in the instance appears — including executive groups, project teams, and access control groups.

Three Types of Reference Qualifiers

TypeHow it worksBest for
Static Fixed encoded query that never changes. Set in the "Reference qual" field on the dictionary entry. Example: active=true^type=assignment Simple filters that don't depend on context
Dynamic Encoded query with JavaScript-like variables that resolve at run time. Can use javascript: prefix to call a function. Filters based on current user, form values, or context
Scripted Full JavaScript function (in "Reference qual script" field) returning an encoded query string or GlideRecord. Most flexible. Complex logic — multiple conditions, external lookups, user role-based filtering
⚠
Exam Trap — Qualifiers Are UI-Only Reference Qualifiers only filter the UI picker dialog. They do NOT enforce a constraint on what value can be stored. A script or API call that directly sets the field to any sys_id will succeed regardless of whether that record would appear in the qualifier filter. For true enforcement, combine with a Data Policy or Business Rule validation.
Section 2

Field-Level ACLs

Access Control Lists (ACLs) in ServiceNow enforce both table-level and field-level security. A field-level ACL specifies who can read or write a specific field on a specific table.

Field ACLs work as an additional layer on top of table ACLs. A user must have table-read access to even open a record, and then field-read ACLs determine which specific fields they can see. Similarly, table-write access allows saving, but field-write ACLs control which fields they can modify.

📘
Core Concept — ACL Evaluation Order ACLs are evaluated in a specific order. For field access: (1) check if the user has the required role on the field-level ACL. (2) If no field ACL exists, inherit from the table-level ACL. (3) Table-level ACL grants access to all fields unless overridden by a more specific field ACL. This "most specific wins" principle means field ACLs can tighten (or loosen) table-level access for specific fields.

Read vs. Write Field ACLs

  • Read ACL on a field — if the user fails this ACL, the field is hidden/blank in forms and API responses. The Table API response simply omits fields the requesting user can't read.
  • Write ACL on a field — if the user fails this ACL, the field appears read-only on the form. API attempts to write it are silently ignored (the field is not updated).
⚠
Exam Trap — API Field Omission, Not Error When a user queries via the Table API for a record containing fields they can't read, those fields are simply absent from the JSON response — no error, no indication. Similarly, if they PATCH a field they can't write, the write is silently ignored — no error returned. This silent behavior is a security feature but can be confusing when debugging integration issues.
Section 3

Row-Level Access Control

Beyond field-level ACLs, ServiceNow also supports row-level access control through the ACL framework. A table read ACL can include a condition script that evaluates whether the current user should see this specific record.

For example: an ACL on incident with a condition script that returns current.caller_id == gs.getUserID() means users can only see incidents they reported themselves. Without this ACL, they'd see all incidents.

  • Row-level ACLs use condition scripts that return true (allow) or false (deny)
  • They are evaluated for every record returned by a query — this can be slow on large result sets
  • GlideRecord queries do NOT automatically skip rows blocked by ACLs when running in scripts — use gr.canRead() to check manually
Section 4

Principal Class Filtering for CMDB

Principal Class Filtering is a CMDB-specific mechanism for controlling which CI class can be selected in a Reference field that points to cmdb_ci or any of its child tables.

Without Principal Class Filtering, a Reference field to cmdb_ci allows selecting any CI of any class — a server, a database, an application service, a network device. For a Change Request's "Affected CI" field, you might want to restrict it to only hardware CIs (cmdb_ci_hardware) or only servers (cmdb_ci_server).

To configure Principal Class Filtering:

  1. Navigate to System Definition → Dictionary
  2. Find the Reference field entry (e.g., change_request.cmdb_ci)
  3. Open the Reference Specification related list at the bottom
  4. Click New and enter the CI class name you want to allow (e.g., cmdb_ci_hardware)
  5. You can add multiple classes — users can pick CIs from any of the listed classes
📘
Core Concept — How It Works in the Picker When Principal Class Filtering is active on a Reference field, the CI picker shows only CIs whose sys_class_name matches one of the allowed classes (or their children). If you allow cmdb_ci_hardware, the picker shows all hardware CIs including cmdb_ci_computer and cmdb_ci_server because those extend it. The filtering respects the inheritance hierarchy.
Section 5

Field Encryption

For sensitive data like SSNs, credit card numbers, or passwords, ServiceNow supports field-level encryption. When enabled on a field, values are encrypted at rest in the database and only decrypted for users with the appropriate role.

  • Configured via the Encrypted checkbox on the dictionary entry
  • The snc_internal or a custom role is required to view decrypted values
  • Encrypted fields cannot be used as coalesce fields in Import Sets (the encrypted value doesn't match a plain-text comparison)
  • Reports and list views show masked values for users without decrypt access
💡
Tip — Edge Guard Encryption ServiceNow's Edge Encryption feature allows sensitive fields to be encrypted on the client side before transmission — the ServiceNow cloud never sees the plain text. This is different from standard field encryption where the cloud holds the encryption keys. Edge Encryption requires on-premise infrastructure. Standard field encryption is simpler but the keys are managed by ServiceNow.
Exam Quick Reference

Common Exam Traps — Reference Qualifiers & Field Security

  • Reference Qualifiers filter the UI picker only — they don't block API or script writes
  • Three qualifier types: Static (fixed query), Dynamic (context variables), Scripted (JavaScript function)
  • Field read ACL failure = field omitted from API response silently (no error)
  • Field write ACL failure = write silently ignored in API (no error)
  • Principal Class Filtering restricts which CI class can be selected in CMDB Reference fields — configured via Reference Specification related list
  • Principal Class Filtering respects inheritance — allowing cmdb_ci_hardware also allows all classes that extend it
  • Encrypted fields cannot be used as coalesce fields in imports
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Reference Qualifiers & Field Security Quiz 1 / 4

A REST API integration sets the "assignment_group" field on an Incident to a sys_id of a group that is filtered out by the Reference Qualifier on that field. What happens?

💡 Explanation

B is correct. Reference Qualifiers are purely a UI-side filter — they narrow what appears in the reference field picker dialog for users interacting with forms. They have zero enforcement power over scripts, REST API calls, or import sets. Any valid sys_id can be written to a reference field via API regardless of Reference Qualifier configuration. For server-side enforcement, you need a Data Policy or a Before Business Rule that validates the value programmatically.

A user with a field-level read ACL failure on the "salary" field queries a record via the Table API. What does the API response contain for that field?

💡 Explanation

C is correct. When a user fails a field-level read ACL, the Table API silently omits that field from the JSON response. There is no error, no placeholder, no indication the field even exists. This is an intentional security feature — revealing that a field exists (even if you can't read its value) could itself be a security leak. Similarly, if a user tries to PATCH a field they don't have write ACL on, the write is silently ignored. This silent behavior is a common source of confusion when debugging integrations — always check ACLs when fields mysteriously disappear from API responses.

A Change Request's "Affected CI" reference field points to cmdb_ci (all CIs). The change manager wants to restrict the picker so only servers (cmdb_ci_server) and hardware (cmdb_ci_hardware) can be selected. Which mechanism should be used?

💡 Explanation

C is correct. Principal Class Filtering is the CMDB-specific mechanism for restricting which CI class can appear in reference fields that point to cmdb_ci or its children. Configured via the Reference Specification related list on the dictionary entry, it also respects inheritance — allowing cmdb_ci_hardware also allows all classes extending it (like cmdb_ci_computer, cmdb_ci_server). Option A (static qualifier) could work but would need to handle the full inheritance hierarchy manually and breaks when new subclasses are added. Principal Class Filtering is the designed solution for this exact use case.

A payroll application has an "employee_ssn" field that is encrypted. An integration that imports employee records uses the serial_number field of this encrypted field as a coalesce key. What problem will occur?

💡 Explanation

B is correct. Encrypted fields store values in encrypted form in the database. When an Import Set tries to coalesce (match existing records) on an encrypted field, it compares the encrypted stored value against the plain-text import value — these will never match. The result: every import creates a new record instead of updating the existing one, flooding the database with duplicates. This is a well-known limitation. The fix: use a non-encrypted field (like asset_tag or a hash) as the coalesce key when working with imports that touch encrypted fields.

Score: 0 / 4
Next: Data Certification & Lifecycle →