Application Files and Modules

In ServiceNow, every application you create is composed of several key types of files. These are not like Word documents or PDFs; they are digital blueprints that define how data looks, how users interact with it, and how they find it. The three main types covered in this chapter are: Forms, Lists, and Modules.

What is an Application File? An Application File is any component that makes up your application. Think of it as a single Lego brick. Each brick has a specific shape and function. In ServiceNow, common application files include: - Tables: The database structure that holds records (e.g., a ‘Trouble Ticket’ table). - Forms: The visual interface for viewing, entering, or editing a single record (e.g., the screen where you fill in a ticket description). - Lists: The table view showing multiple records at once (e.g., a spreadsheet of all open tickets). - Modules: Navigation links that appear in the left-hand menu (the Application Navigator) to quickly access specific lists or forms. - Business Rules: Scripts that run automatically on records. - Client Scripts: Scripts that run in the user’s browser. For the exam, focus on Forms, Lists, and Modules as the core “application files” you need to manage.

Forms: The Single Record View A Form is the primary way users see and edit one record at a time. For example, when an IT helpdesk agent clicks on a specific incident ticket, they see a Form with fields like ‘Short Description’, ‘Priority’, ‘Assigned to’, and ‘State’. Each field maps to a column in the underlying database table.

Key points about Forms:

Lists: The Multiple Record View A List displays a table of many records from the same table. It looks like a spreadsheet or an Excel sheet. Users can filter, sort, and perform bulk actions on the records. For instance, a list of ‘All Incidents’ shows columns for each field and rows for each incident.

Key points about Lists:

Modules: The Navigation Shortcuts Modules are links that appear in the left-hand navigation menu (the Application Navigator). They act as shortcuts to specific Lists, Forms, or even reports. For example, a module called “My Open Incidents” might take you directly to a filtered list showing only incidents assigned to you.

Key points about Modules:

How They Work Together Imagine you built an app for tracking company assets (laptops, monitors, etc.). You would create a table called ‘Asset’. ServiceNow automatically generates a Form for entering a new asset and a List that shows all assets. You then create a Module called ‘All Assets’ in the app’s navigation. When a user clicks that module, they see the List. They can then click a specific asset to open its Form and edit details.

Why This Exists Before platforms like ServiceNow, developers had to write custom code for every form, list, and menu option. That was slow and error-prone. ServiceNow generates these automatically from the table definition, which saves massive time. But you still need to manage them — rename fields, hide unnecessary columns, reorder tabs — to match business needs. That is the “manage application files” skill.

How It Replaces Older Methods In legacy systems, a form was a separate web page coded manually. A list required a separate script to query the database. ServiceNow abstracts all that: you define the table, then the platform creates standard forms and lists. You simply tweak them using the Application Builder (formerly Application Studio) or the related configuration menus. This means you spend less time coding and more time designing user experience.

Important Terminology - Table: The database container for a set of records (like a spreadsheet’s sheet). - Record: One row in a table (e.g., one specific trouble ticket). - Field: One column in a table (e.g., ‘Priority’). - View: A specific layout of a Form or List (e.g., a mobile-friendly view). - Related List: A list embedded on a Form showing records from another table that are linked (e.g., all comments on an incident).

What Beginners Often Miss Beginners often think forms and lists are fixed, but they are highly customisable. They also confuse modules with forms — a module is a navigation link, not the form itself. And they forget that modifying a form field (like making it mandatory) affects how users interact with that field across all lists and forms using that table.

Exam Relevance The SNOW-CAD exam expects you to know exactly how to create, configure, and navigate these elements. You will be asked about where to find the form builder, how to add a field to a list, and how to create a module that points to a specific filter. You must know the difference between a ‘Module’ and a ‘View’ and that modules live in the Application Navigator.

An IT professional at a mid-sized company, Sarah, is tasked with building a simple change management app in ServiceNow. She is new to the platform but needs to deliver it in two days. Here is how she uses Application Files and Modules.

Step 1: Define the Table Sarah creates a new table called ‘Change Request’ with fields like ‘Change Title’, ‘Description’, ‘Risk Level’, ‘Implementation Date’, and ‘Status’. The platform automatically creates a default Form and a default List for this table. She doesn’t have to write any code yet.

Step 2: Customise the Form Sarah opens the ‘Form Design’ option (from the context menu on the table’s name). She reorders fields so that the most important ones (‘Change Title’, ‘Risk Level’) appear at the top. She moves ‘Implementation Date’ to a new section called “Schedule”. She also makes ‘Risk Level’ mandatory because a change cannot be approved without it. She deselects ‘Show’ for a field that only internal admins need, hiding it from end-users. This is all done through drag-and-drop.

Step 3: Configure the List Sarah goes to the ‘List Control’ or ‘List Layout’ settings. She chooses which columns appear in the list view (e.g., ‘Change Title’, ‘Status’, ‘Risk Level’). She sets the default sort order to newest first. She also enables ‘List Edit’ so users can change the status of multiple changes at once without opening each form. This saves time during the weekly review.

Step 4: Create Modules Sarah wants users to find her app easily. She navigates to the application menu (Application Navigator) and creates a new module. She names it “All Changes” and points its link to the Change Requests list, filtered to show only active records (status not equal to ‘Closed’). She creates another module called “My Changes” which links to a list filtered by the current user’s name. These modules appear under the “Change Management” section in the left menu.

Step 5: Test and Deploy Sarah logs in as a test user. She sees the modules. Clicking “All Changes” shows the list she designed. She clicks a row and sees the form she configured. She can edit, save, and use the related lists if she adds any (like ‘Approval’ records). She then realises that the form’s ‘Description’ field is too small, so she goes back to the Form Design and increases its height. The changes are saved immediately.

Real-World Challenges - Permissions: Sarah must ensure that only change managers can see the ‘Risk Level’ field. She does this by creating a different form view for managers and another for requestors. - Performance: If the list contains thousands of records, she might need to configure a ‘Filter Condition’ so users see only relevant records (e.g., last 30 days). - Mobile: She creates a separate mobile view for the form because the standard layout is too wide for phones.

What Sarah Learned Managing application files is not just about clicking buttons. It is about understanding how each change affects the user experience. A poorly designed form leads to data entry errors. A cluttered list slows down work. A missing module means users cannot find the app at all. In her daily work, Sarah spends about 20% of her app building time on forms and lists, because they are the interface between the system and the human. The SNOW-CAD exam tests her ability to make these design decisions correctly.