ServiceNow Developer Course | Lesson 6 | Dictionary Entries, Field Types, Parent & Child Tables

Lesson Focus: ServiceNow Dictionary Entries + Field Types + Table Relationships (Parent/Child/Extension)

1) Dictionary entries: what they do to fields

• Dictionary entries are the configuration that defines what fields exist in a table and how each field behaves.
• They control:
  • Field name
  • Field data type (e.g., string/text, integer, date, date-time, boolean, choice)
  • Maximum length / size (e.g., string length)
  • Mandatory behavior (required fields)
  • Read-only behavior (prevents editing after generation)
  • Default values (e.g., default status = “New”)
  • For choice fields: dropdown options via a choice list

2) Example table: “Credit Card Application”

A conceptual credit-card application table with fields such as:

• Customer Name
• Application Number
• Card Type
• Status
• KYC Complete (yes/no)
• Application Date (date)
• Approval Date (date + time)

3) Field data types and expected UI behavior

• String/Text: stores alphabetic text (e.g., Customer Name) and enforces max length (examples mention up to 40/100).
• Integer: stores numeric-only values (e.g., Annual Income).
• Boolean: stores True/False (e.g., KYC Completed).
• Choice: provides dropdown selections (e.g., Status, Card Type, Card Category).
• Date: shows a calendar date picker (e.g., Application Date).
• Date/Time: shows date plus time picker (e.g., Approval Date).

4) Mandatory, read-only, and default examples

• Mandatory
  • A star (*) appears on the form.
  • Submission is blocked until required fields are filled.
• Read-only
  • After a value is generated (e.g., application/credit-card number), other users can’t edit it.
• Default values
  • Status defaults to “New”
  • Card/application defaults are illustrated as preselected values on the form.

5) Where dictionary entries are configured

• Open dictionary definitions:
  • Go to System Definition → Dictionaries
• Apply dictionaries to a specific table:
  • Use the table’s internal name, derived from the table label (example format: x_core_credit_card_application)
• Dictionaries can be used to affect the behavior of fields already on the table.

---

Tutorial Walkthrough: Creating and Applying Dictionaries + Records

6) Create a table and fields

• Create a new table (example label: “Credit Card Application One”).
• Add fields:
  • Customer Name (string)
  • Mobile Number (string)
  • Annual Income (integer)
  • Status (choice)
  • Card Type (choice)
  • KYC Completed (boolean)
  • Application Date (date)
  • Approval Date (date/time)

7) Configure list layout ordering

• Use Configure → List Layout to reorder fields visible in the list view.

8) Add dictionaries and then verify behavior on forms/records

• Initially, after inserting records/rows, dropdowns/mandatory behavior won’t appear until dictionary entries are applied.
• Apply dictionary properties, for example:
  • Customer Name → mandatory
  • Status → choice list with options (default = “New”)
  • Card Type → choice list (examples: Silver/Platinum/Gold)
  • KYC Completed → boolean mapping True/False
• Verification steps:
  • Open Show Form
  • Create/update records
  • Confirm mandatory star/error, dropdown defaults, and checkbox True/False display

---

Parent Table / Child Table / Extension Table Concepts

9) Parent table vs child table

• Parent table
  • Holds common fields shared by multiple record types.
  • Example: a generic “Complaint” task-like set (number, state, priority, assigned_to, assigned_group, short description).
• Child tables
  • Represent specialized record types.
  • Example: Credit Card Complaint, ATM Complaint, etc.
  • Child tables add specific fields on top of inherited common fields.

10) Extension table (inheritance behavior)

• The extension feature allows child tables to inherit parent fields automatically, preventing duplication.
• With extension:
  • Parent fields appear in the child table without recreating them
  • Child-specific fields are added separately

---

Practical Extension Example: “Credit Card Compliant” Extending “Task”

11) Create the parent/child relationship

• In ServiceNow, Task already functions like the parent for many ticket/complaint-like records.
• Create a new table like “Credit Card Compliant” that extends Task.
• Add child-specific fields:
  • Card Number (string)
  • Card Type (choice)
  • Category (choice)
• Adjust list layout so child-specific fields appear on the list view.

12) Form design integration

• Use Form Design to place child-specific fields on the form alongside inherited Task fields.
• Child fields then become editable and can be configured further with dictionaries for dropdown values.

13) Add dictionary entries for child choice fields

• Configure dictionaries for child-specific fields, setting:
  • Category choice values (e.g., Card Blocked / PIN not received / Fraud-related categories)
  • Card Type choice values (e.g., Gold/Platinum/Silver)

14) Verification: inherited fields + child-specific fields together

• Demonstrate record creation where:
  • Inherited Task fields (e.g., Number, Priority, State, Assigned to) appear automatically
  • Child-specific fields (Card Number/Card Type/Category) use dropdowns/field behavior
  • Updates and dropdown selections work as expected

---

Key Takeaways

• Dictionary entries define field behavior (mandatory, read-only, defaults, and UI type via data types).
• Choice fields need dictionary-managed choice lists to produce dropdowns and defaults.
• Parent/child tables with extension avoid duplicated field definitions by inheriting common fields (e.g., from Task or another parent).

---

Main Speaker / Source

• Presenter from the Lucky Tech YouTube channel (the narration/teaching voice throughout the lesson).