Form Design and Layout in ServiceNow refers to the process of configuring and customizing the visual presentation and structure of forms used to display and capture record data within the platform. As a Certified Application Developer, understanding form design is essential for creating intuitive and efficient user interfaces.

**Form Layout** defines how fields, sections, and related lists are arranged on a form. Administrators and developers can configure form layouts using the Form Designer or Form Layout tools. The Form Designer provides a drag-and-drop interface that allows developers to add, remove, and rearrange fields, sections, and formatters without writing code.

**Key Components of Form Design:**

1. **Sections**: Forms can be divided into logical sections to group related fields together, improving readability and navigation. Sections can be expanded or collapsed by users.

2. **Fields**: Individual data elements displayed on the form. Developers control which fields appear, their order, and whether they span one or two columns.

3. **Formatters**: Special elements like Activity streams, Process flows, or custom UI macros that enhance form functionality beyond standard fields.

4. **Related Lists**: Displayed at the bottom of forms to show related records from other tables, providing contextual information.

5. **Views**: Multiple form layouts (views) can be created for the same table, allowing different user groups to see different arrangements of fields based on their roles or needs.

**Best Practices:**
- Place the most critical fields at the top of the form for quick visibility.
- Use sections to logically organize fields and reduce clutter.
- Leverage UI Policies and Client Scripts to dynamically show, hide, or make fields mandatory based on conditions.
- Create role-specific views to tailor the experience for different user groups.
- Keep forms clean and avoid overloading them with unnecessary fields.

Form design directly impacts user productivity and data quality, making it a fundamental skill for application developers building custom applications on the ServiceNow platform.

Form Views and Sections are fundamental concepts in ServiceNow's Application User Interface that control how data is presented and organized on forms.

**Form Views:**
Form Views define different layouts of a form for the same table. A single table can have multiple views, each displaying different fields, arrangements, and sections depending on the user's role, context, or purpose. For example, an Incident table might have a 'Default' view for general users, an 'ITIL' view for IT staff, and a 'Self-Service' view for end users. Views allow administrators to tailor the user experience without creating separate tables.

Views can be configured using the Form Designer or Form Layout. Administrators can specify which view loads based on conditions such as user roles, URL parameters, or UI policies. The system uses the 'sysparm_view' parameter to determine which view to render.

**Form Sections:**
Sections are subdivisions within a form view that group related fields together logically. They help organize information into manageable blocks, improving readability and user experience. Each section can have a header (caption) and can contain one or two columns of fields.

Sections can be expanded or collapsed, allowing users to focus on relevant information. Common examples include grouping contact details in one section, technical details in another, and resolution information in a separate section.

**Key Points:**
- Multiple views can exist per table, each with unique field arrangements and sections.
- Sections within views organize fields into logical groupings.
- The Form Designer provides a drag-and-drop interface to configure views and sections.
- View rules can automatically direct users to specific views based on conditions.
- Sections support split layouts (one-column or two-column formatting).
- Annotations can be added to sections for additional guidance.

As a Certified Application Developer, understanding Form Views and Sections is essential for creating intuitive, role-based user interfaces that enhance productivity and ensure users see only the information relevant to their tasks.

List Views and Configuration in ServiceNow are fundamental components of the Application User Interface that allow users and developers to display, organize, and interact with records from database tables in a structured tabular format.

**List Views** present multiple records from a table in rows and columns, similar to a spreadsheet. Each row represents a record, and each column represents a field from that table. Users can interact with list views to sort, filter, search, and perform actions on records efficiently.

**Key Features of List Views:**

1. **Column Configuration:** Administrators and users can customize which columns (fields) appear in a list view. This is done through the List Layout configuration, accessible via the personalize list gear icon or through the List Layout module under System UI.

2. **List Controls:** These include sorting (clicking column headers), filtering using condition builders, breadcrumb filters, and column search to narrow down displayed records.

3. **Views:** Multiple views can be created for the same table, each showing different column arrangements. For example, an Incident table might have a 'Default' view, an 'ESS' (Employee Self-Service) view, and custom views tailored for specific roles or purposes. Views are identified by name and can be assigned to different user roles.

4. **List Editing:** Depending on configuration, users can perform inline editing directly within list views, enabling quick updates without opening individual records.

5. **List Context Menus:** Right-clicking on list elements provides options such as grouping, showing visual task boards, exporting data, and creating quick reports.

6. **Personalization vs. Configuration:** Regular users can personalize their own list views, while administrators can configure list layouts that apply globally or per role.

7. **List v2 and v3:** ServiceNow has evolved its list component, with List v3 offering improved performance and modern UI capabilities.

For Certified Application Developers, understanding list view configuration is essential for building user-friendly applications that present data effectively and align with organizational requirements and role-based access needs.

Client Scripts in ServiceNow are JavaScript code segments that run on the client side (in the user's web browser) when forms are loaded, modified, or submitted. They are a fundamental component of the Application User Interface and play a critical role in enhancing the user experience by providing real-time interactivity without requiring server round-trips.

There are four main types of Client Scripts:

1. **onLoad**: Executes when a form is first loaded in the browser. It is commonly used to set default field values, hide or show fields, or display informational messages to the user upon opening a record.

2. **onChange**: Triggers when a specific field value changes on the form. This is useful for dynamically updating related fields, performing field validations, or modifying the form layout based on user input.

3. **onSubmit**: Runs when the user submits or saves the form. It is typically used to validate data before it is sent to the server. If validation fails, the script can abort the submission and prompt the user to correct errors.

4. **onCellEdit**: Executes when a field value is changed in a list view (list editing). This allows developers to apply logic when users edit records directly from a list rather than opening the full form.

Client Scripts have access to the GlideForm (g_form) API, which provides methods to manipulate form fields, such as setting values, making fields mandatory, showing or hiding fields, and displaying messages. They can also use the GlideUser (g_user) API to access information about the currently logged-in user.

Best practices for Client Scripts include minimizing server calls using GlideAjax for asynchronous operations, keeping scripts lightweight to avoid performance degradation, and using UI Policies for simple show/hide or mandatory logic instead of writing custom scripts. For ServiceNow Certified Application Developers, understanding Client Scripts is essential for building responsive, user-friendly applications that deliver seamless form interactions and robust client-side validation.

GlideForm, commonly referred to as g_form, is a client-side JavaScript API in ServiceNow that provides methods to interact with and manipulate forms displayed in the user interface. It is one of the most frequently used client-side APIs by ServiceNow developers and is available in Client Scripts, UI Policies, and other client-side scripting contexts.

The g_form API allows developers to customize form behavior dynamically without requiring page reloads. Key capabilities include:

**Field Manipulation:** Developers can get and set field values using methods like getValue(), setValue(), and clearValue(). For example, g_form.setValue('priority', '1') sets the priority field to the value 1.

**Field Visibility and Access:** Methods such as setVisible(), setReadOnly(), and setDisabled() control whether fields are shown, editable, or disabled. This enables dynamic form layouts based on user input or conditions.

**Mandatory Fields:** The setMandatory() method allows developers to make fields required or optional dynamically, ensuring data integrity based on specific business logic.

**UI Messages and Notifications:** g_form provides addInfoMessage(), addErrorMessage(), showFieldMsg(), and hideFieldMsg() to display contextual messages to users, improving the user experience with real-time feedback.

**Option List Management:** For choice and reference fields, methods like addOption(), removeOption(), and clearOptions() allow dynamic modification of available selections.

**Form Submission Control:** Developers can use submit() to programmatically submit forms and flash() to highlight fields requiring attention.

**Section Management:** Methods like setSectionDisplay() allow toggling the visibility of form sections dynamically.

**Label Management:** The setLabel() method enables changing field labels at runtime.

Important considerations when using g_form include that it is only available on the client side and should not be used in server-side scripts. It works within the scope of the current form and is most commonly utilized in onChange and onLoad Client Scripts and UI Policies. Proper use of g_form enhances form interactivity, enforces business rules at the UI level, and significantly improves the overall user experience in ServiceNow applications.

GlideUser (g_user) is a client-side API in ServiceNow that provides methods to retrieve information about the currently logged-in user. It is available in all client-side scripts, including Client Scripts, UI Policies, and UI Actions (when running on the client). The g_user object is automatically instantiated and accessible without any additional initialization.

Key Properties and Methods:

1. **g_user.userName** - Returns the username (user_id) of the currently logged-in user.

2. **g_user.firstName** - Returns the first name of the current user.

3. **g_user.lastName** - Returns the last name of the current user.

4. **g_user.userID** - Returns the sys_id of the current user record.

5. **g_user.hasRole('role_name')** - Returns true if the current user has the specified role. This is commonly used to control UI behavior based on user roles. Note that users with the 'admin' role will return true for any role check.

6. **g_user.hasRoleExactly('role_name')** - Returns true only if the user has the exact specified role, without the admin override behavior.

7. **g_user.hasRoleFromList('role1,role2')** - Returns true if the user has at least one role from the comma-separated list of roles provided.

8. **g_user.getClientData('key')** - Retrieves client data that was previously set using putClientData() in a server-side script (typically a UI Script or Display Business Rule).

9. **g_user.getFullName()** - Returns the full name of the currently logged-in user.

Important Considerations:
- g_user is a client-side object and should not be confused with GlideUser on the server side.
- Role checks using hasRole() should be used carefully since admin users bypass role restrictions.
- The getClientData() method enables efficient client-server data transfer without requiring additional AJAX calls.
- g_user helps developers personalize the user interface, enforce security, and conditionally display or hide elements based on user attributes and roles, making it essential for ServiceNow application development.

UI Policies in ServiceNow are powerful client-side rules that dynamically control the behavior and appearance of form fields without requiring scripting knowledge. They are a key concept for ServiceNow Certified Application Developers and play a critical role in Application User Interface customization.

UI Policies allow administrators and developers to dynamically change the properties of fields on a form based on specific conditions. The three primary actions a UI Policy can perform are:

1. **Make fields mandatory** – Require users to fill in specific fields when certain conditions are met.
2. **Make fields read-only** – Prevent users from editing certain fields based on defined criteria.
3. **Make fields visible/hidden** – Show or hide fields dynamically depending on the form's current state.

UI Policies evaluate conditions in real time on the client side, meaning changes occur instantly as users interact with the form without requiring a server round-trip. They are configured through a point-and-click interface, making them accessible to non-developers.

Key components of a UI Policy include:
- **Table**: The table the policy applies to.
- **Conditions**: The criteria that trigger the policy (e.g., when Priority equals 1).
- **UI Policy Actions**: The field-level changes (mandatory, read-only, visible) applied when conditions are met.
- **Script**: Optional advanced scripting using 'Execute if true' and 'Execute if false' script blocks for complex logic.
- **Order**: Determines the sequence of execution when multiple policies exist.
- **Reverse if false**: Automatically reverts changes when conditions are no longer met.
- **Run on**: Specifies whether the policy runs on form load, field change, or both.

UI Policies take precedence over UI Policy Actions set by Access Control Lists (ACLs) and are preferred over Client Scripts for simple field manipulations because they are easier to maintain and debug. They support both global and table-specific scoping. For the Certified Application Developer exam, understanding UI Policies, their execution order, and how they interact with other client-side mechanisms like Client Scripts is essential.

UI Actions in ServiceNow are powerful tools that allow developers to add custom functionality to forms and lists within the platform. They appear as buttons, links, or context menu items that users can interact with to perform specific operations. UI Actions are a fundamental component of the Application User Interface and are essential knowledge for the ServiceNow Certified Application Developer exam.

UI Actions can be configured to run on the server side, client side, or both. Server-side UI Actions execute GlideRecord scripts and other server-side APIs, while client-side UI Actions use GlideForm (g_form) and GlideUser (g_user) APIs to manipulate the user interface without requiring a page reload. When both client and server scripts are needed, the UI Action first executes the client script and then submits to the server for further processing.

Key properties of UI Actions include:

1. **Name**: The label displayed on the button, link, or menu item.
2. **Table**: The table on which the UI Action is available.
3. **Action Name**: A unique identifier used for programmatic reference.
4. **Show Insert/Show Update**: Controls visibility based on whether the record is new or existing.
5. **Form/List Context Menu**: Determines where the UI Action appears.
6. **Condition**: A script or condition that controls when the UI Action is visible.
7. **Script**: The actual code that executes when the UI Action is triggered.

Security is managed through ACLs and roles, ensuring only authorized users can access specific UI Actions. The 'Roles' field restricts visibility to users with designated roles.

Developers can use the `current` object in server scripts and leverage `gsftSubmit()` or `gel()` functions in client scripts. Best practices include using conditions to limit visibility, adding proper role-based access, and ensuring client-side validation before server submission.

UI Actions are scoped to applications in the scoped application model, making them portable across instances. They are essential for customizing ServiceNow workflows and enhancing the user experience by providing contextual actions directly within forms and lists.

Record Producers are a powerful feature in ServiceNow that allow users to create records in any table through the Service Catalog interface, rather than navigating directly to the target table's form. Essentially, a Record Producer acts as a catalog item that, when submitted, generates a record in a specified table, making the process more user-friendly and accessible.

In the context of the ServiceNow Certified Application Developer exam and Application User Interface, Record Producers play a critical role in streamlining data entry and improving the user experience. They are commonly used to allow end-users to submit requests, report incidents, or create records without needing direct access to backend tables.

Key characteristics of Record Producers include:

1. **Table Association**: Each Record Producer is linked to a specific target table where the record will be created upon submission. For example, a Record Producer can be configured to create records in the Incident, Change Request, or any custom table.

2. **Variables and Field Mapping**: Record Producers use catalog variables that map to fields on the target table. When a user fills out the form and submits it, the variable values are automatically populated into the corresponding table fields.

3. **Service Catalog Integration**: Record Producers appear in the Service Catalog alongside other catalog items, providing a consistent and intuitive interface for users to interact with.

4. **Scripting Support**: Developers can use scripts, including onSubmit scripts, to manipulate data, perform validations, or execute business logic before or after the record is created.

5. **Access Control**: Record Producers can be restricted using user criteria, roles, or conditions to control who can access and submit them.

6. **Customization**: They support UI policies, client scripts, and catalog client scripts to enhance form behavior and validation.

Record Producers bridge the gap between the Service Catalog and underlying tables, enabling developers to create streamlined, user-friendly interfaces for record creation while maintaining control over data integrity and workflow processes.

Data Policies in ServiceNow are powerful mechanisms used to enforce data consistency and integrity across the platform, regardless of how data is entered into the system. Unlike UI Policies, which only apply when users interact with forms through the standard browser interface, Data Policies extend their enforcement to all data entry points, including web services, import sets, direct API calls, and other inbound integrations.

Data Policies allow administrators and developers to set fields as mandatory, read-only, or visible/hidden based on specific conditions. They function similarly to UI Policies but operate at a deeper level within the platform's data layer. When a Data Policy is configured, it ensures that the defined rules are consistently applied whether a record is created or updated through the UI, a REST API, a SOAP call, or any other method of data manipulation.

Key features of Data Policies include:

1. **Cross-Channel Enforcement**: They apply universally across all interfaces and integration points, ensuring data quality regardless of the data source.

2. **Condition-Based Rules**: Administrators can define conditions under which certain fields become mandatory or read-only, providing dynamic data governance.

3. **UI Policy Integration**: When a Data Policy is created, there is an option to automatically generate a corresponding UI Policy, ensuring consistent behavior on forms as well.

4. **Table-Specific Configuration**: Data Policies are configured per table, allowing granular control over different record types.

5. **Order of Execution**: Data Policies are evaluated after Business Rules but play a critical role in the overall data validation process.

For Application Developers, understanding Data Policies is essential because they ensure that custom applications maintain data integrity across all access methods. They are particularly important in enterprise environments where multiple systems interact with ServiceNow through various integration channels. By implementing Data Policies effectively, developers can prevent incomplete or inconsistent data from entering the system, reducing errors and improving overall application reliability and data quality throughout the platform.

Client-Side Debugging Techniques in ServiceNow are essential skills for Certified Application Developer professionals, enabling them to identify and resolve issues within the Application User Interface efficiently.

**1. Browser Developer Tools:**
Modern browsers (Chrome DevTools, Firefox Developer Tools) are the primary debugging instruments. The Console tab allows developers to view JavaScript errors, log messages, and execute code in real-time. The Network tab helps monitor AJAX calls, API requests, and GlideAjax responses between the client and server.

**2. JavaScript Logging:**
Using `jslog()` is a ServiceNow-specific method for client-side logging. Developers can enable JavaScript logging by adding `javascript.log` debug parameters or by navigating to the JavaScript Log and enabling it through the System Diagnostics module. The `console.log()`, `console.warn()`, and `console.error()` methods also help trace variable values and execution flow.

**3. Breakpoints:**
Setting breakpoints in the Sources tab of browser DevTools allows developers to pause script execution at specific lines in Client Scripts, UI Policies, or UI Actions. This enables step-by-step inspection of variable states and logic flow.

**4. GlideAjax Debugging:**
When debugging asynchronous client-server communication via GlideAjax, developers should verify callback functions, inspect XML/JSON responses in the Network tab, and ensure Script Include accessibility.

**5. Field Watcher and Debug Tools:**
ServiceNow provides built-in utilities like the Field Watcher to monitor field value changes in real-time. Adding `?sysparm_field_watcher=true` to the URL activates this feature.

**6. Try-Catch Blocks:**
Wrapping client-side code in try-catch blocks helps gracefully handle exceptions and provides meaningful error messages for troubleshooting.

**7. ServiceNow Debug Module:**
The Session Debug modules (Debug CSS, Debug JavaScript) help identify rendering and scripting issues within the platform UI.

Mastering these techniques enables developers to efficiently diagnose client script errors, UI policy failures, form rendering issues, and communication breakdowns between client and server components in ServiceNow applications.

Formatters and UI Macros are powerful tools in ServiceNow that allow developers to customize and enhance the user interface beyond standard form and list layouts.

**Formatters:**
Formatters are special elements that can be added to form layouts to display non-field content. Unlike regular form fields that map directly to database columns, formatters render custom content such as related lists, activity streams, or other dynamic UI elements directly within a form. They appear in the Form Layout configuration under the 'Formatters' section and can be dragged onto the form layout just like regular fields. Common built-in formatters include the Activity Formatter (which displays the activity stream on a record), the Process Flow Formatter (which shows visual workflow stages), and the Parent Breadcrumbs Formatter. Formatters essentially act as placeholders on the form that invoke specific rendering logic to display specialized content.

**UI Macros:**
UI Macros are reusable Jelly script components that define custom HTML, CSS, and JavaScript content to be rendered in the ServiceNow interface. They serve as the underlying mechanism behind formatters and other UI customizations. UI Macros are created in the 'UI Macros' table (sys_ui_macro) and use Jelly templating language combined with HTML to generate dynamic content. Developers can create custom UI Macros to build unique interface components, embed custom widgets, or render specialized visualizations. They can be referenced within form formatters, UI Pages, and other UI components.

**Relationship Between the Two:**
Formatters and UI Macros work hand-in-hand. When you add a formatter to a form layout, it typically calls a corresponding UI Macro to render the actual content. Developers can create custom formatters by first building a UI Macro with the desired rendering logic and then registering it as a formatter. This combination allows for highly customizable form experiences while maintaining reusability across multiple forms and applications. Together, they provide a flexible framework for extending ServiceNow's standard interface capabilities to meet specific business requirements.