Mastering Field Attributes: Crafting Stellar User Experiences and Data Integrity

Ever found yourself staring at a form, wondering why a particular field behaves the way it does? Or perhaps you’ve been tasked with making a field mandatory only under certain conditions, or ensuring a dropdown only shows relevant options. If so, you’re delving into the powerful world of field attributes – the unsung heroes that dictate how fields behave, interact, and present data to users. These seemingly small configurations are absolutely crucial for building intuitive user experiences, maintaining pristine data integrity, and ultimately, making your platform truly work for your organization.

In this comprehensive guide, we’ll peel back the layers of field attributes, exploring everything from making fields mandatory or read-only to dynamically filtering options and calculating values. We’ll discuss the various tools at your disposal, providing practical explanations, real-world examples, and even a few troubleshooting tips to keep you on the right track. Whether you’re a budding administrator, a seasoned developer, or preparing for your next technical interview, understanding these concepts is paramount.

Making Fields Behave: Mandatory and Read-Only Controls

One of the most fundamental aspects of form design is controlling data entry. You need to ensure users provide critical information, and conversely, prevent them from altering data that shouldn’t be touched. This is where mandatory and read-only controls come into play. But it’s not just about a simple checkbox; platforms offer multiple layers of control, each with its own use case and best practice.

The Five Pillars of Field Control

When it comes to dictating whether a field is mandatory or read-only, you have a powerful arsenal of tools. Let’s break down the five primary methods, as suggested by our reference, and understand their nuances:

1. Dictionary Properties (Default Behavior)

   At the most foundational level, a field’s mandatory or read-only status can be set directly in its dictionary definition. This is the “source of truth” for the field across the entire instance, applying universally wherever that field appears (unless overridden). Think of it as the field’s default state.

   • When to Use: When a field *must always* be mandatory or read-only, regardless of the table, form, or user interaction. For example, a “Short Description” field on a task table is almost universally mandatory because every task needs a basic summary.
   • How it Works: You navigate to the field’s dictionary entry, and directly check the “Mandatory” or “Read only” checkbox. Simple, global, and effective for baseline requirements.
   • Real-world Example: Setting the “Number” field of an Incident record as read-only. Once an incident number is generated, it should not be manually changed. Similarly, “Caller” on an Incident form is usually mandatory by default.

2. Dictionary Overrides (Specializing Behavior)

   What if a field (like “Priority”) is inherited from a parent table (like “Task”) but needs different behavior on a child table (like “Incident”)? This is precisely where dictionary overrides shine. They allow you to modify a field’s dictionary properties for a specific table without altering the parent table’s definition.

   • When to Use: Crucial for specializing inherited fields. If “Description” is optional on a generic “Task” but *must* be mandatory on an “Incident,” a dictionary override is your go-to. This keeps your parent table clean and allows child tables to adapt.
   • How it Works: You create a dictionary override for the specific field on the child table and then check “Override Mandatory” or “Override Read only” to set its new status. We’ll dive deeper into dictionary overrides later, but their role here is critical.
   • Real-world Example: The “Priority” field might have a default value of ‘4 – Medium’ on the ‘Task’ table. But for ‘Incident’ records, your organization might want the default ‘Priority’ to be ‘5 – Planning’ or even ‘3 – Moderate’. A dictionary override on the ‘Incident’ table for the ‘Priority’ field allows this specific adjustment.

3. UI Policies (Client-Side, Dynamic Control)

   Now we move into dynamic behavior. UI Policies are client-side logic that applies only to the user interface (the form itself) and can change a field’s mandatory, read-only, or visibility status based on conditions on the form. They are non-scripted (though they can run scripts) and are processed after client scripts and page loads.

   • When to Use: When a field’s status needs to change dynamically based on user input or other field values on the form. For example, if “Additional Comments” becomes mandatory only if the “State” is set to “Resolved.”
   • How it Works: You define conditions (e.g., “State is Resolved”) and then specify actions (e.g., “Set ‘Additional Comments’ field as Mandatory: True”).
   • Real-world Example: On an Incident form, if the “Resolution Code” is “Solved (Workaround),” you might want to make the “Workaround Details” field mandatory. UI Policies handle this perfectly.

4. Data Policies (Server-Side, Data Integrity)

   Data Policies are the “big brother” to UI Policies, focusing purely on data integrity at the server level. While they can mimic UI Policy behavior on the UI (if “Apply to UI” is checked), their primary purpose is to enforce data standards regardless of how data is entered – be it through a form, import set, web service, or script.

   • When to Use: When a field *must* be mandatory or read-only to ensure data quality, even if someone tries to bypass the UI (e.g., through an API call or an import). This is critical for data consistency across all entry points.
   • How it Works: Similar to UI Policies, you define conditions and actions, but the enforcement happens on the server. If “Apply to UI” is checked, it also acts like a UI Policy on the form.
   • Real-world Example: Ensuring that the “Configuration Item” field is always filled for a “Change Request” before it moves to the “Implement” state, even if someone updates the state via a script. A data policy ensures this data integrity server-side.

5. Client Scripts (`g_form.setMandatory()`, `g_form.setReadOnly()`)

   For the most complex and highly dynamic scenarios, client scripts provide ultimate flexibility. Using the `g_form` API, you can programmatically control a field’s mandatory or read-only status based on intricate logic that might be too complex for UI Policies.

   • When to Use: When you need highly custom, real-time control that depends on multiple fields, user roles, external data, or complex calculations. For instance, making a field mandatory only if two other fields meet specific criteria AND the user belongs to a certain group.
   • How it Works: You write JavaScript code (e.g., `g_form.setMandatory(‘field_name’, true);` or `g_form.setReadOnly(‘field_name’, true);`) within a Client Script (e.g., `onChange`, `onLoad`, `onSubmit`).
   • Real-world Example: You might have a complex approval workflow where a “Justification” field becomes mandatory only if the requested item’s total cost exceeds a certain threshold AND the request is submitted by a user without a manager. This kind of multi-condition logic is best handled with client scripts.

Troubleshooting Mandatory/Read-Only Conflicts

With so many ways to control a field, conflicts can arise. The general order of precedence (from highest priority to lowest) is often: Client Script > UI Policy > Data Policy (if ‘Apply to UI’ is true) > Dictionary Override > Dictionary Property. If a field isn’t behaving as expected, check these in reverse order:

• Client Scripts: Is there an `onLoad` or `onChange` script overriding your setting?
• UI Policies: Are there conflicting UI policies? Check their “Order” field.
• Data Policies: Is there an active data policy enforcing a different state?
• Dictionary Overrides: Is there an override on the specific table?
• Dictionary: What’s the base setting for the field?
• Review Logs: Sometimes, the browser’s developer console (F12) can show client script errors.

Interview Relevance

This is a favorite interview question! Being able to articulate the different methods, their order of precedence, and when to choose each one demonstrates a deep understanding of platform architecture and best practices for configuration versus scripting. Always emphasize data integrity as a key reason for using Data Policies.

Setting the Stage: Default Values for a Seamless Start

Imagine opening a form and many of the fields you expect to fill in are already populated with sensible values. That’s the magic of default values! They streamline the user experience, reduce manual input, and ensure consistent data capture from the get-go. Instead of users having to remember to select “New” for a state field or pick their own name, the system does it for them.

How to Set a Default Value on a Field

The core idea is to populate some default values whenever a new record form is opened. This can be achieved through several mechanisms, much like setting mandatory fields:

• Dictionary Default Value: The most common and straightforward method. For a string, integer, or choice field, you can simply type in the default value in the “Default value” field of the dictionary entry. For reference fields, you can use `javascript:gs.getUserID()` for the current user, or `javascript:gs.getCurrentUser().getDepartmentID()` for more complex lookups.
  • When to Use: For static defaults or simple script-based defaults (like the current user) that apply universally.
  • Real-world Example: Setting the “State” field of a new record to “New” or “Draft”. Setting “Requested for” to `javascript:gs.getUserID()` to automatically populate with the current logged-in user.
• Dictionary Overrides: Just like with mandatory/read-only, you can override the default value for a specific child table. This is incredibly useful for specializing inherited fields.
  • When to Use: When a child table needs a different default than its parent.
  • Real-world Example: A “Task” might default “Priority” to 4, but an “Incident” might override this to 3 to emphasize immediate action.
• Client Scripts (`g_form.setValue()`): For highly dynamic default values that depend on complex client-side logic or user interaction. An `onLoad` Client Script can evaluate conditions and set values.
  • When to Use: When the default value depends on other fields on the form, user roles, or is fetched from external data *after* the form loads.
  • Real-world Example: Defaulting a “Location” field based on the “Company” selected, after an AJAX call retrieves the company’s primary location.
• UI Policies (Set Field Value): UI Policies can also set field values, though they are usually triggered by conditions. This is useful for defaulting a field once a certain condition is met on the form.
  • When to Use: When you want to set a default value *after* a user performs an action or meets specific criteria on the form.
  • Real-world Example: If “Category” is “Software,” default “Assignment Group” to “Software Support.”
• Business Rules (Before Insert): For server-side default values that must be enforced before a record is committed to the database, regardless of how it was created.
  • When to Use: For defaults that are critical for data integrity and should be set even if the UI is bypassed.
  • Real-world Example: Automatically setting the “Created By” field if it somehow gets left blank, or calculating a unique identifier before insertion.

Troubleshooting Default Values

• Overriding Defaults: Remember the order of execution. Client-side scripts and UI Policies executed on load will run *after* dictionary defaults are applied. A UI Policy with a higher order might overwrite a default set by another policy.
• Script Errors: If using JavaScript in dictionary defaults or client scripts, ensure there are no syntax errors. Check the system logs for Business Rules and the browser console for Client Scripts.
• Data Type Mismatch: Ensure the default value matches the field’s data type (e.g., don’t try to default a reference field with a string that isn’t a sys_id).

Interview Relevance

Discussing default values shows your commitment to user experience and efficiency. Highlight the difference between client-side (UX) and server-side (data integrity) defaulting mechanisms.

Mastering Field Relationships: Reference Qualifiers

Reference and List fields are incredibly powerful, allowing you to link records across your platform. But imagine a “Configuration Item” field showing *every single CI* in your database – a nightmare for users! That’s where Reference Qualifiers become indispensable. They are the gatekeepers that restrict the data displayed in these fields, ensuring users see only relevant options, thereby improving accuracy, performance, and user experience.

Three Types of Reference Qualifiers

There are three distinct types, each designed for different levels of complexity and dynamism:

1. Simple Reference Qualifier

Description: This is the most straightforward type, using a fixed query string to filter records. It’s like applying a permanent filter to the lookup list.

When to Use: Ideal for static, unchanging filters. If you always want to show only active users, or only hardware CIs, a simple qualifier is perfect.

How to Use:

1. Navigate to the dictionary entry of your reference field.
2. Locate the “Reference qualifier” field.
3. Enter your query string directly. This string follows the standard ServiceNow query syntax (e.g., `field_name=value^another_field=another_value`).

Example: If you have a “Managed By” reference field to the User table, and you only want to show active users, you’d set the simple reference qualifier to: active=true.

Another Example: For a “CI Type” field that references the `cmdb_ci_hardware` table, you might want to show only CIs with a specific class. install_status=1^operational_status=1 (to show only installed and operational CIs).

2. Dynamic Reference Qualifier

Description: Dynamic qualifiers are a step up in flexibility. Instead of a fixed string, they use a pre-defined “Dynamic Filter Option” that can adapt based on the context of the current record or user. They are reusable, making them great for consistent filtering across multiple fields.

When to Use: When you need contextual filtering that can be reused. For instance, showing users within the same company as the current record, or CIs related to the currently selected assignment group. They’re excellent for maintaining consistency and reducing redundant configuration.

How to Use:

1. Create a Dynamic Filter Option: Go to System Definition > Dynamic Filter Options.
   • Click “New.”
   • Give it a descriptive “Name” (e.g., “Users in Same Assignment Group”).
   • Select the “Table” it applies to (e.g., “User”).
   • Define the “Conditions” using a script or condition builder. For instance, a script might say: javascript: "assignment_group=" + current.assignment_group; (this would typically be defined within the script field of the dynamic filter option itself, referencing the current record’s group).
   • Ensure it’s “Active.”
2. Apply to Reference Field:
   • Go to the dictionary entry of your reference field.
   • In the “Reference qualifier” field, select “Dynamic” as the qualifier type.
   • Choose your newly created Dynamic Filter Option from the dropdown.

Example: Imagine an “Approver” field on a Change Request, and you want to show only users who belong to the same “Approval Group” as specified on the change request. You’d create a Dynamic Filter Option that builds a query like `sys_idIN[sys_ids_of_users_in_approval_group]` based on the `current.approval_group` field.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

Description: This is the most powerful and flexible type, utilizing custom JavaScript code to construct the query string. It allows for highly complex, multi-conditional, and dynamic filtering that might involve looking up data from multiple tables or intricate logic.

When to Use: For scenarios where simple or dynamic qualifiers aren’t sufficient. This includes situations requiring multiple conditions, querying related tables, or implementing very specific business logic (e.g., filtering users who have a specific role AND belong to a certain department AND are currently active).

How to Use:

1. Navigate to the dictionary entry of your reference field.
2. In the “Reference qualifier” field, select “Advanced” as the qualifier type.
3. Prefix your JavaScript code with javascript:. The script must return a valid encoded query string.

Example: Filtering the “Assigned To” field on an Incident to show only users who are members of the currently selected “Assignment Group” AND who have the “itil” role.

javascript: (function() {
    var group = current.assignment_group;
    if (!group) {
        return 'sys_idINEMPTY'; // Return no users if no group is selected
    }
    var userList = [];
    var grMember = new GlideRecord('sys_user_grmember');
    grMember.addQuery('group', group);
    grMember.query();
    while (grMember.next()) {
        userList.push(grMember.user.toString());
    }

    // Now, filter these users further by role
    var finalUserList = [];
    var grUser = new GlideRecord('sys_user');
    grUser.addQuery('sys_id', 'IN', userList.join(','));
    grUser.addQuery('active', true); // Only active users
    grUser.addQuery('roles', 'CONTAINS', 'itil'); // Must have ITIL role
    grUser.query();
    while (grUser.next()) {
        finalUserList.push(grUser.sys_id.toString());
    }

    if (finalUserList.length > 0) {
        return 'sys_idIN' + finalUserList.join(',');
    } else {
        return 'sys_idINEMPTY';
    }
})();

This advanced example demonstrates fetching group members, then filtering those members further by their roles and active status. It’s powerful, but requires careful scripting.

Understanding the Differences

• Simple vs. Dynamic: Simple is static and fixed; Dynamic is contextual and reusable. Dynamic qualifiers abstract complex logic into a reusable option, whereas Simple qualifiers are hardcoded query strings.
• Dynamic vs. Advanced: Dynamic leverages pre-built, reusable logic within a Dynamic Filter Option; Advanced allows for completely custom, ad-hoc JavaScript logic directly on the field. Advanced is for unique, complex scenarios, while Dynamic is for standard, repeatable contextual filters.
• Simple vs. Advanced: Simple uses a direct, non-scripted query string; Advanced uses JavaScript to programmatically construct a query string, offering unparalleled flexibility.

Troubleshooting Reference Qualifiers

• Syntax Errors: Even a tiny typo in a simple qualifier can break it. For advanced qualifiers, syntax errors in JavaScript are common. Always test thoroughly.
• Returning an Empty Query: Ensure your advanced script always returns a valid query string, even if it’s `sys_idINEMPTY` to show no results. An invalid return can cause errors.
• Performance: Complex advanced qualifiers (especially those with many `GlideRecord` queries) can impact form load times. Optimize your scripts! Cache results if possible or simplify logic.
• Debugging Advanced Qualifiers: Use `gs.log()` or `gs.info()` within your script to output values to the system logs, helping you trace the script’s execution and the generated query.

Interview Relevance

Reference qualifiers are a cornerstone of platform customization. Interviewers often ask about the types, their differences, and when to use each. Being able to explain the trade-offs between flexibility, reusability, and performance is key.

Smart Choices: Dependent Values (Cascading Dropdowns)

Ever used a website where selecting a country automatically filters the available states, and then selecting a state filters the available cities? This cascading effect greatly enhances usability and data accuracy. In platforms, this is achieved through Dependent Values, which filter choices in one field based on the selection made in another field.

Why Dependent Values Matter

• Improved User Experience: Users are presented with fewer, more relevant options, reducing cognitive load and speeding up data entry.
• Enhanced Data Consistency: Prevents users from selecting invalid combinations (e.g., a subcategory that doesn’t belong to the chosen category).
• Reduced Errors: Minimizes the chance of selecting incorrect data, leading to cleaner reporting and better automation.

Steps to Configure Dependent Values

Let’s use the classic Category/Subcategory example to illustrate:

1. Identify Parent and Dependent Fields:
   • Parent Field: Category (e.g., `u_category` on a custom table).
   • Dependent Field: Subcategory (e.g., `u_subcategory` on the same table).
2. Configure the Parent Field:
   • Ensure your parent field (Category) is a “Choice” type and has its list of possible values defined (e.g., Hardware, Software, Network).
3. Configure the Dependent Field:
   • Navigate to the dictionary entry of the dependent field (Subcategory).
   • In the “Dependent Field” attribute dropdown, select your parent field (Category).
   • Now, define choices for the dependent field:
     • Go to the “Choices” related list at the bottom of the dictionary entry.
     • When you create a new choice for “Subcategory” (e.g., “Laptop”), you’ll see a “Dependent value” field. In this field, enter the *exact* value of the “Category” it depends on (e.g., “Hardware”).
     • Repeat this for all subcategory choices, linking them to their respective parent category values.

Example Walkthrough

Imagine your ‘Category’ field has choices: ‘Hardware’, ‘Software’, ‘Network’.

For your ‘Subcategory’ field, you would define choices like:

• Choice: Laptop, Dependent value: Hardware
• Choice: Desktop, Dependent value: Hardware
• Choice: Printer, Dependent value: Hardware
• Choice: Operating System, Dependent value: Software
• Choice: Application, Dependent value: Software
• Choice: Router, Dependent value: Network
• Choice: Switch, Dependent value: Network

Now, when a user selects “Hardware” in the Category field, only “Laptop,” “Desktop,” and “Printer” will appear in the Subcategory field. Change “Category” to “Software,” and “Operating System” and “Application” will appear.

Troubleshooting Dependent Values

• Mismatching Values: The “Dependent value” for the child choice MUST exactly match the “Value” of the parent choice. Case sensitivity matters!
• Incorrect Field Type: Ensure both parent and child fields are “Choice” or “String” types that can host choices.
• No Choices Defined: If no choices are defined for the dependent field or none match the selected parent value, the dependent field will appear empty.
• Form Layout: Ensure both fields are on the same form for the dependency to function correctly client-side.

Interview Relevance

This is a common requirement and a good question to demonstrate your practical configuration skills. Explain the benefits of UX and data quality.

Behind the Scenes Calculations: Calculated Values

Sometimes, a field’s value isn’t directly input by a user but is derived from other fields on the record. Instead of manually updating it or writing complex Business Rules to calculate it, you can use a Calculated Value dictionary property. This allows a field to automatically display a value based on a script, typically using the `current` object to access other field values.

What is a Calculated Value?

A calculated field is a read-only field whose value is computed dynamically. It’s stored in the database if “Calculated” and “Virtual” are both false, or it’s a virtual field that computes on the fly and is not stored if “Virtual” is true. This distinction is important for performance and data storage.

When to Use Calculated Values

• Derived Data: When a field’s value is a direct result of other fields (e.g., “Total Price” from “Quantity” and “Unit Price”).
• Real-time Display: For values that need to be seen immediately on the form but don’t require manual input.
• Simplifying Automation: Reduces the need for complex “Before Insert/Update” Business Rules for simple calculations.

How it Works

1. Go to the dictionary entry of the field you want to make calculated.
2. Check the “Calculated” checkbox.
3. If you want the field to be dynamic and not stored in the database, also check “Virtual” (this is often the case for display-only calculated fields).
4. In the “Calculation” field, write a JavaScript function that returns the desired value. This function has access to the `current` object, allowing it to read other field values on the record.

Example: Calculating the “Total Price” of an item based on “Quantity” and “Unit Price” fields.

javascript: (function calculateTotalPrice() {
    var quantity = current.u_quantity; // Assuming u_quantity is your quantity field
    var unitPrice = current.u_unit_price; // Assuming u_unit_price is your unit price field

    if (quantity && unitPrice) {
        return quantity * unitPrice;
    }
    return 0; // Default to 0 if values are missing
})();

This script would be placed in the “Calculation” field. Whenever `u_quantity` or `u_unit_price` changes (and the record is saved/refreshed), `u_total_price` would update.

Troubleshooting Calculated Values

• Performance Impact: If your calculation script is complex or queries other tables frequently, it can slow down record loads, especially if it’s not virtual (meaning it recalculates on every query).
• Script Errors: Debug your JavaScript carefully. Use `gs.log()` to check intermediate values in the system logs.
• Data Type Mismatch: Ensure your script returns a value compatible with the field’s data type.
• Read-Only Nature: Remember calculated fields are read-only. If users need to input or override, this isn’t the right solution.

Interview Relevance

This demonstrates your understanding of data modeling and when to use derived fields versus direct user input. Discussing the “Virtual” option shows awareness of performance considerations.

Unlocking Field Behavior: What Are Attributes?

Beyond the checkboxes for mandatory and read-only, there’s a whole universe of less obvious but equally powerful modifiers: Attributes. Attributes are special key-value pairs (or just keys) that you can add to a field’s dictionary entry or a table’s collection entry to modify its behavior in various ways, often impacting the UI or server-side processing.

Attributes: The Hidden Configurators

Attributes literally change the field’s behavior. They are typically added in the “Attributes” field on the dictionary entry (comma-separated if multiple). Here are some commonly used ones beyond those mentioned in the reference:

• no_email=true: Prevents the content of this field from being included in email notifications when the record is updated. Useful for sensitive information that shouldn’t leave the platform via email.
• no_attachment=true: Prevents attachments from being added to the form or record for this specific field. (More commonly used at the collection level, but can be field-specific if needed).
• no_add_me=true: On a reference field, this prevents the “Add Me” button from appearing, which normally allows a user to quickly assign themselves.
• tree_picker=true: Transforms a reference field into a hierarchical tree picker, useful for fields like “Configuration Item” where CIs are organized in a hierarchy.
• display=true: Marks a field as the “display value” for a reference to its table. For example, on the User table, the `name` field has `display=true`, so when you reference a user, you see their name, not their sys_id.
• ref_auto_completer=AJAXTableCompleter,ref_ac_columns=field1;field2,ref_ac_order_by=field1: A set of attributes used to enhance reference field auto-completion, showing additional columns in the dropdown and sorting them. This greatly improves UX for users trying to find specific records.
• max_length=200: Explicitly sets the maximum number of characters allowed in a string field, overriding the default.
• glide_list=true: Transforms a string field into a “List” collector, allowing users to select multiple values from a reference table and store their sys_ids as a comma-separated string. (Not to be confused with a List field type, this applies to a string field).

Real-world Example

Imagine you have a “Comments” field where users can type. If these comments are internal and contain sensitive troubleshooting steps, you might add no_email=true to the field’s dictionary attributes. This ensures that even if an email notification is triggered for a record update, the content of this particular “Comments” field won’t be exposed in the email.

Troubleshooting Attributes

• Spelling Mistakes: Attributes are case-sensitive and must be spelled precisely. A single typo will render them ineffective.
• Conflicts: Some attributes might conflict with other UI settings or client scripts. Test thoroughly.
• Order of Precedence: Attributes generally define default UI behavior but can often be overridden by UI Policies or Client Scripts.

Interview Relevance

Knowing common attributes demonstrates your practical experience with customization beyond basic field configuration. It shows you understand how to fine-tune the user interface and data handling.

The Table’s DNA: Collection Fields and Global Attributes

When you create a new table, something special happens in the dictionary: a “Collection” type entry is automatically created. This isn’t a field on the table itself, but rather represents the *entire table*. It’s like the table’s DNA, holding attributes and properties that apply globally to all records within that table.

What is a Collection Field?

A dictionary entry with the “Collection” type doesn’t correspond to a specific column. Instead, it serves as a central point for applying properties that affect the entire table. Any attributes, read-only settings, or other modifications applied to this entry will govern the behavior of *all* records on that table.

When to Use the Collection Field

• Global Table Behavior: When you need to apply an attribute or setting that impacts the entire table, not just a single field.
• Attachment Control: The most common use case is enabling or disabling attachments for an entire table.
• Email Notification Control: Preventing all records on a table from triggering notifications (though usually handled by Business Rules).

How to Enable/Disable Attachment on the Form Using Attributes (Q53)

This is a classic example of using the collection field:

1. Navigate to the dictionary entries for your table (e.g., `incident`).
2. Find the entry where “Type” is “Collection” (it will typically have no “Column name”).
3. In the “Attributes” field, add no_attachment=true.

Once saved, no one will be able to add attachments to any Incident record. Removing the attribute will re-enable them. This is a very clean and global way to control attachments.

Troubleshooting Collection Field Attributes

• Overriding with UI Policies/Client Scripts: While a collection attribute might globally disable something (like attachments), specific UI Policies or Client Scripts *could* potentially try to re-enable or disable them conditionally on forms. The collection attribute sets the baseline.
• Specific Field vs. Collection: Be clear whether you want to disable something for *one* field or *all* fields/the entire record. `no_attachment` on a specific field prevents attachments *for that field*, which is less common than disabling them for the whole record via the collection.

Interview Relevance

This question differentiates between field-level and table-level configurations. It demonstrates a holistic understanding of how properties propagate across the platform.

Specializing Behavior: Dictionary Overrides Revisited

We’ve touched on Dictionary Overrides for mandatory/read-only and default values, but their importance warrants a dedicated section. They are absolutely critical in platforms that leverage table inheritance (like ServiceNow, where Incident, Problem, and Change all extend from Task).

What are Dictionary Overrides?

A Dictionary Override allows a field in a child table to have a different value or behavior than the same field in its parent table. Without overrides, any change to an inherited field on the parent table would automatically apply to all child tables, which is rarely desirable for specialization. Overrides provide a way to “branch off” and customize inherited fields for specific child tables while maintaining the parent-child relationship.

Why are they so important?

• Maintain Parent Integrity: You can modify a field’s behavior on a child table without affecting the parent table or other child tables.
• Specialization: Allows child tables to adapt inherited fields to their unique processes and requirements.
• Best Practice: Essential for proper table extension and customization, promoting clean architecture.

Properties You Can Override

Dictionary overrides are incredibly versatile. You can override a wide range of properties, including:

• Default value: Change the initial value of the field for records on the child table. (e.g., Priority defaults to 5 on Task, but 4 on Incident).
• Mandatory: Make the field mandatory (or optional) specifically on the child table.
• Read-only: Make the field read-only (or editable) specifically on the child table.
• Reference qualifier: Apply a different set of filters to a reference field on the child table.
• Calculated value: Implement a different calculation script for the field on the child table.
• Display value: Change how the field’s value is displayed (less common for overrides, but possible).
• Max length: Adjust the maximum character limit for string fields on the child table.
• Column label: Change the label of the field specifically for the child table (e.g., “Short Description” on Task, but “Summary” on Incident).
• Dependent field: Alter which field the current field is dependent on.
• Attributes: Add or modify specific attributes for the field on the child table.

Real-world Example

Consider the “Description” field, inherited from the “Task” table. On the generic “Task” table, you might allow it to be optional. However, for an “Incident” (a child of Task), a detailed description is critical for resolution. You would create a dictionary override for the “Description” field on the “Incident” table and check “Override Mandatory” to ‘True’. This ensures incidents always require a description, while tasks still allow it to be optional.

Troubleshooting Dictionary Overrides

• Incorrect Table: Ensure the override is applied to the correct child table.
• Inherited vs. Custom: You can only override inherited fields. If a field is custom to the child table, it won’t appear in the override options for its parent.
• Order of Precedence: Remember that UI Policies and Client Scripts can still override dictionary override settings on the client side.
• Multiple Overrides: A field can only have one dictionary override per child table.

Interview Relevance

Dictionary overrides are a key concept for anyone working with inherited tables. Being able to explain their purpose, how they work, and what properties can be overridden is a strong indicator of platform architectural understanding.

Conclusion: The Art of Effective Field Attributes

As we’ve journeyed through the various facets of field attributes, it’s clear that they are far more than just technical configurations. They are the building blocks of a well-designed, user-friendly, and data-rich platform. From ensuring essential data is always captured (mandatory fields) to streamlining user input (default values, dependent fields), and ensuring contextual relevance (reference qualifiers), each attribute plays a pivotal role.

Mastering these attributes – understanding their nuances, their order of precedence, and when to apply each method – is a hallmark of an effective platform administrator or developer. It’s about making informed decisions: choosing dictionary properties for global consistency, dictionary overrides for specialization, UI policies for dynamic client-side control, data policies for server-side data integrity, and client scripts for complex, programmatic behavior.

By thoughtfully applying these field attributes, you’re not just configuring a system; you’re crafting an experience that empowers users, upholds data quality, and ultimately drives the success of your organization’s digital workflows. So, dive in, experiment, and keep learning – the world of field attributes is rich with possibilities!