Troubleshooting Form Submission Errors: Common Issues & Fixes

By /






Resolving Form Submission Problems: A Comprehensive Guide


Resolving Form Submission Problems: A Comprehensive Guide

In the world of IT Service Management and platform development, forms are the primary interface for users to interact with systems, report issues, and request services. When form submissions go awry, it can lead to significant disruptions, frustrated users, and a backlog of unaddressed tasks. This article dives deep into common form submission problems, their root causes, and actionable solutions, drawing from practical experience and common interview questions.

Whether you’re a seasoned administrator or just starting out, understanding how to troubleshoot and resolve these issues is crucial for maintaining smooth operations and efficient workflows.

Understanding Form Submission Fundamentals

Before we tackle problems, let’s quickly recap how forms typically work and the common methods for creating records. In platforms like ServiceNow, forms are often the front-end for creating records in underlying tables. These records can represent anything from an incident or a change request to a user or a group.

Common Methods for Record Creation

It’s important to know that records aren’t just created manually through forms. The platform offers several avenues:

  • Record Producer: A specialized type of catalog item that creates records in a backend table based on user input from a service catalog form.
  • Email: Inbound email actions can parse incoming emails and create records (e.g., creating an incident from an email).
  • GlideRecord: This is the core API for server-side scripting in ServiceNow. It allows developers to create, read, update, and delete records programmatically. Many automated processes rely on GlideRecord.
  • Form: The standard user interface for manually entering data and creating a single record.
  • Excel Sheet: Data can be imported from an Excel file, creating multiple records at once.
  • External Systems: Integrations via APIs or other methods can also create records.

When a form submission fails, the issue could stem from any of these creation methods, or more commonly, from the configuration of the form itself and the associated business logic.

Common Form Submission Problems and Solutions

Let’s address some of the most frequent headaches encountered when forms don’t behave as expected.

1. Form Submits, but Data is Missing or Incorrect

This is a classic scenario. The user clicks “Submit,” the form disappears, and then they discover that some fields are empty or contain the wrong information.

Potential Causes & Solutions:

  • Incorrect Field Values/Types:

    Troubleshooting: Check the dictionary entry for the field. Ensure the field type is appropriate (e.g., not trying to put text into a number field). For reference fields, confirm the correct sys_id is being passed.

    Reference Field Values: If you’re setting values via script, remember that for reference fields, you need to provide the sys_id. The current.setValue('field_name', 'sys_id_value'); method is your friend here. If you need to display a human-readable value without knowing the sys_id beforehand, current.setDisplayValue('field_name', 'display_value'); can be useful, but it’s often better to ensure the correct sys_id is used for data integrity.

  • Business Rules (Server-Side Logic):

    Troubleshooting: Server-side business rules can modify or abort record insertions/updates. Look for “before” or “after” business rules on the table the form is submitting to. A “before” rule might be incorrectly clearing a field, or an “after” rule might be updating it with incorrect data.

    Example: Consider a rule that’s supposed to populate a `u_assigned_to` field based on the `u_caller`. If the `u_caller` is invalid or not found, the `u_assigned_to` might remain empty.

  • UI Policies and Client Scripts:

    Troubleshooting: While UI Policies and Client Scripts primarily run on the client-side (browser), they can indirectly affect submitted data. A UI Policy might make a field read-only, preventing a user from entering data, or a client script might clear a field based on certain conditions just before submission.

    g_form.setMandatory(): Client scripts can also dynamically set fields as mandatory. If the condition for making it mandatory is met, but the user doesn’t fill it, the form might fail to submit or submit with incomplete data. Conversely, if a script accidentally clears a required field, the submission could fail validation.

  • Reference Qualifiers:

    Troubleshooting: Reference qualifiers restrict the choices available in a reference field. If a user selects a value that’s subsequently filtered out by a qualifier (e.g., via a business rule or a dynamic qualifier that changes after submission), the submitted record might have an invalid reference.

    Types of Reference Qualifiers:

    • Simple: Basic filter like active=true.
    • Dynamic: Uses a script include to generate the query, allowing context-based filtering.
    • Advanced: Custom JavaScript code for complex filtering.

    Ensure your qualifier logic is correct and doesn’t unintentionally exclude valid records.

  • Mandatory Fields Not Filled:

    Troubleshooting: The most straightforward cause. Check if any mandatory fields (marked with a red asterisk) are empty. This can be enforced by dictionary properties, dictionary overrides, UI Policies, or Data Policies.

    Making Fields Mandatory: This can be done via dictionary properties, dictionary overrides, UI policies, data policies, and server-side scripts (though usually UI/Data policies are preferred for form-level behavior).

Troubleshooting Tip: Check the System Logs

When data is missing, always start by examining the System Logs (specifically, System Logs > System Log > All) and the JavaScript Log in the browser’s developer console. These logs often contain error messages or clues about what went wrong during the submission process.

2. Form Fails to Submit with an Error Message

This is often more obvious, as the user sees an explicit error preventing them from proceeding.

Potential Causes & Solutions:

  • Script Errors (Client or Server):

    Troubleshooting: Error messages directly point to code issues. If it’s a client-side script error (e.g., in a UI Policy script or client script), check the browser’s developer console. If it’s server-side, check the System Logs.

    Example: A client script trying to access a field that doesn’t exist on the form, or a server-side business rule with a syntax error.

  • Data Validation Failures:

    Troubleshooting: This occurs when data entered violates defined constraints. This could be:

    • Mandatory fields: As mentioned earlier, if a required field is empty.
    • Unique field constraints: Trying to create a record with a value already present in a field that’s marked as unique (e.g., username, email).
    • Regex pattern mismatches: If a field has a regular expression validation and the input doesn’t match.
    • Data Policy violations: Data policies enforce mandatory/read-only states at both client and server levels.
  • Permissions/ACL Issues:

    Troubleshooting: The user might not have the necessary permissions to create or write to the target table. This is a common cause of submission failures, especially in complex environments.

    Interview Relevance: “Can we add permissions to the users and groups? Which is the best practice?”

    A: Yes, we can add roles to users and groups manually or via scripts using GlideRecord. The best practice is to add permissions (roles) to groups. This way, when an employee leaves and is removed from the group, their associated roles and permissions are automatically revoked, simplifying user lifecycle management.

    Script Example (Adding Role to Group):

    
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', 'sys_id_of_your_group'); // e.g., '477a05d153013010b846ddeeff7b1225'
grpRole.setValue('role', 'sys_id_of_your_role'); // e.g., '2831a114c611228501d4ea6c309d626d'
grpRole.insert();

  • Workflow/Approval Issues:

    Troubleshooting: If the form submission is tied to a workflow or approval process, and there’s an issue within the workflow (e.g., a script throwing an error in a workflow activity, or an invalid approval condition), it might prevent the record from being fully created or transitioned.

  • Attachment Issues:

    Troubleshooting: If the form includes an attachment field, errors can occur if there are restrictions on file size, type, or if there’s an issue with the attachment’s storage.

    Controlling Attachments: You can disable attachments on a form by adding the no_attachment attribute to the collection field (the field representing the table itself) in the dictionary entry.

3. Form Submits Instantly, No Record Created

This is perhaps the most frustrating: the user goes through the motions, but nothing appears to have happened.

Potential Causes & Solutions:

  • Aborted Action (Server-Side):

    Troubleshooting: A “before” business rule might have called current.setAbortAction(true);, preventing the insert/update operation from proceeding. This is often used for strict validation.

    Example: Preventing an incident from being created if a similar incident already exists and is open.

    Interview Relevance: “Preventing incident closure if tasks are open”

    Scenario: You want to prevent an incident from being closed if there are still open incident tasks associated with it. This requires a “before” business rule.

    Logic:

    • Table: Incident
    • When: Before
    • Operation: Update
    • Condition: current.state.changesTo(3) (assuming state 3 is ‘Closed’)
    • Script:
      
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed'
grTask.query();

if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open tasks.');
    current.setAbortAction(true);
}
  • Asynchronous Processing:

    Troubleshooting: Some operations might be designed to run asynchronously (in the background) for performance reasons. If there’s a delay, it might appear as if nothing happened immediately.

    Check Pending Actions: In ServiceNow, you can check System Diagnostics > Pending Actions to see scheduled or queued background jobs.

  • JavaScript Errors (Client-Side):

    Troubleshooting: A client-side script error occurring just before submission might prevent the submission logic from executing correctly. Check the browser’s developer console.

  • Record Producer Logic Issues:

    Troubleshooting: If using a record producer, the “Create Task” or “Script” field within the record producer might contain errors or logic that prevents the record from being inserted.

  • Network Issues:

    Troubleshooting: Though less common for internal systems, intermittent network problems between the user’s browser and the server could cause a submission to fail silently.

Advanced Scenarios & Best Practices

Beyond the common hiccups, let’s look at some more advanced configurations and best practices that prevent issues before they start.

1. Managing User Permissions and Roles

Properly managing who can do what is fundamental. As highlighted in interview questions, effective role management prevents unauthorized access and simplifies administration.

Q: How to create a user account using script?

A: You can create a user using GlideRecord.


var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();

Q: How to create a group using script?

A: Similar to users, use GlideRecord.


var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'testing';
// manager field typically requires sys_id of a user
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1';
newGr.email = 'testing@tcs.com';
newGr.description = 'test';
newGr.insert();

Q: How to add permissions to user/group account using script?

A: Permissions are managed via roles. For users, it’s the sys_user_has_role table. For groups, it’s sys_group_has_role.


// Adding a role to a user
var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', 'sys_id_of_the_user'); // e.g., '62826bf03710200044e0bfc8bcbe5df1'
userRole.setValue('role', 'sys_id_of_the_role'); // e.g., '2831a114c611228501d4ea6c309d626d'
userRole.insert();

// Adding a role to a group
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', 'sys_id_of_the_group'); // e.g., '477a05d153013010b846ddeeff7b1225'
grpRole.setValue('role', 'sys_id_of_the_role'); // e.g., '2831a114c611228501d4ea6c309d626d'
grpRole.insert();

Q: How to add and remove group member from group using script?

A: Use the sys_user_grmember table.


// Adding a group member
var grMem = new GlideRecord('sys_user_grmember');
grMem.user = 'sys_id_of_the_user'; // e.g., '62826bf03710200044e0bfc8bcbe5df1'
grMem.group = 'sys_id_of_the_group'; // e.g., '477a05d153013010b846ddeeff7b1225'
grMem.insert();

// Removing a group member
var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'sys_id_of_the_user');
grMem.addQuery('group', 'sys_id_of_the_group');
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}

2. UI Policies vs. Data Policies

Understanding the difference and appropriate use of UI policies and Data policies is crucial for controlling form behavior.

UI Policies: Primarily client-side. They control field visibility, mandatory status, read-only status, and can execute scripts. They are great for immediate user feedback.

Data Policies: Operate on both client and server sides. They enforce mandatory, read-only, and display states across all data sources (forms, integrations, email). They are essential for data integrity.

“Reverse if false” in UI policies: When checked, the UI Policy actions are undone if the condition becomes false. For example, if a field is made mandatory when a condition is true, it becomes optional again when the condition is false.

“On Load” checkbox in UI policy: If checked, the UI policy runs as soon as the form loads. If unchecked, it only runs when a dependent field changes.

“Inherit” checkbox in UI policies: Allows a UI policy defined on a parent table to be applied to its child tables.

Can you write script in UI policy? Yes, by enabling the “Run scripts” checkbox.

Can we convert UI policy as data policy? Yes, there’s a button for it. However, UI policies controlling views, related lists, or complex scripts might not convert cleanly.

3. Dictionary Overrides for Granular Control

Sometimes, default field behaviors need to be tweaked for specific tables. This is where dictionary overrides shine.

Q: What are dictionary overrides? What are all the properties we can override?

A: Dictionary overrides allow a field in a child table to have different properties than the same field in its parent table. You can override most dictionary attributes, such as Default value, Max length, Mandatory, Read only, Display, Reference Specification, Choice list specification, etc.

Example: The priority field might have a default value of 4 in the parent task table, but you want it to default to 5 in the incident table. A dictionary override on the incident table for the priority field would achieve this.

4. Dependent Values and Calculated Fields

These features help automate data entry and ensure logical consistency.

Dependent Values: Used for creating cascaded dropdowns. For example, selecting a Category (e.g., Hardware) can dynamically filter the available options in the Subcategory field (e.g., Laptop, Desktop, Printer). This is configured in the Dictionary entry for the dependent field.

Calculated Value: A dictionary property that allows a field’s value to be computed automatically based on other fields. This is often achieved using the current object in a script.

Example: A calculated field u_total_cost could be the sum of u_quantity and u_price_per_unit.

Interview Relevance: “What are reference qualifiers, and their types? Explain each one in detail and what is the difference in simple and dynamic, dynamic and advanced, simple and advanced.”

A: Reference Qualifiers restrict the records displayed in reference and list fields. They ensure users select relevant data.

  • Simple: Uses a basic, static query (e.g., active=true^department=IT). Easy to configure directly in the dictionary entry.
  • Dynamic: Leverages a “Dynamic Filter Option” script include. The query is generated dynamically based on context (e.g., showing users from the same department as the caller).
  • Advanced: Uses custom JavaScript in the dictionary entry. Offers the most flexibility for complex logic, allowing interaction with form elements or other server-side logic.

Differences:

  • Simple vs. Dynamic: Simple is static; Dynamic changes based on form context.
  • Dynamic vs. Advanced: Dynamic uses predefined filter options; Advanced allows writing completely custom JavaScript logic.
  • Simple vs. Advanced: Simple is basic filtering; Advanced is full scripting power.

5. Default Values

Setting default values is a simple yet effective way to pre-populate forms and reduce user effort.

How to set default values: This is configured directly within the field’s dictionary entry. When the form loads, if the field is empty, it will be populated with the default value.

Example: Setting the default assignment group for new incident tickets to the “Service Desk” group.

Automating Workflows and Business Logic

Forms are often just the trigger for broader processes. Business rules, workflows, and scripts are key to automating these.

Business Rules for Automation

Business rules are powerful server-side scripts that execute based on conditions when records are inserted, updated, deleted, or queried.

Example: Logic for Closing Child Incidents When Parent is Closed

This is a common requirement to ensure that if a parent incident is resolved and closed, all its related child incidents are also closed.

  • When: After
  • Update: true
  • Condition: current.state.changesTo(7); (Assuming state 7 is ‘Closed’)
  • Script:
    
if (current.state == 7 && current.parent == '') { // Ensure it's a parent incident being closed
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();

    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.update(); // Update the child incident
    }
}

Example: Automatically Closing Associated Incidents When a Problem is Closed

When a problem is identified and resolved, any incidents linked to it should also be closed.

  • When: After
  • Update: true
  • Condition: current.state.changesTo(7); (Assuming state 7 is ‘Closed’)
  • Script:
    
if (current.state == 7) {
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Assuming 'problem_id' is the field linking incident to problem
    grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state value for 'Closed'
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
    }
}

6. Creating Records Programmatically

GlideRecord is the workhorse for creating records via scripts, essential for automation and integrations.

Q: How to create an incident record using script?

A: Using GlideRecord is the standard approach.


var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = 'sys_id_of_caller'; // e.g., '86826bf03710200044e05d94'
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'sys_id_of_ci'; // e.g., 'affd3c8437201000deeabfc8bcbe5dc3'
gr.short_description = 'test record using script';
gr.description = 'test record using script';
gr.assignment_group = 'sys_id_of_assignment_group'; // e.g., 'a715cd759f2002002920bde8132e7018'
gr.insert();

Similar scripts can be used for creating problem records (table problem) and change_request records (table change_request) by modifying the table name and relevant field values.

Technical Notes and Best Practices Summary

Here’s a quick recap of key technical points and best practices to keep in mind:

  • Table Naming: Tables not starting with x_ or u_ are out-of-the-box (OOB).
  • Base Tables: Tables like task and cmdb_ci are base tables.
  • Task Tables: Tables extending task (e.g., incident, problem) share common fields.
  • New Table Creation: By default, 4 ACLs are created if the checkbox is ticked.
  • Number Fields: Require configuration in the Control tab (prefix, digits, auto-number).
  • Table Extension: Inherits sys fields; creates a class field in the parent.
  • Field Types: Be aware of Reference, String, List, Choice, Email, Date/Time, Boolean, Integer, Journal, Attachment.
  • Temporary Tables: Extend import_set_row, data retained for 7 days (can be increased via archive rules).
  • Remote Tables: Provide live data, not stored locally.
  • Table Relationships: Understand One-to-Many and Many-to-Many.
  • current Object: Essential for server-side operations on the current record.
  • sys_db_object table: Contains metadata about all tables.
  • Application Menus: Used to create modules for accessing forms/lists.
  • Process Flow: Visual indicator of a form’s state.
  • Data Lookup Rules: Populate fields based on other field values.
  • Global UI Policy: If checked, applies to all views.
  • Attributes: Modify field behavior (e.g., no_attachment).
  • Collection Field: Represents the table itself in dictionary; affects the whole table.
  • User Delegation: Allows one user to act on behalf of another.
  • Web Services User: For system integrations, cannot log in interactively.
  • Impersonation: Useful for testing user-specific behavior.
  • User Preferences: User-specific settings.
  • Incident vs. Problem: Incident = single interruption; Problem = root cause of recurring issues.
  • Change Management: Formal process for software modifications.

Conclusion

Resolving form submission problems is a fundamental skill for anyone working with IT platforms. By understanding the common causes—from simple data entry errors and mandatory fields to complex script logic and permission issues—you can systematically diagnose and fix these problems.

Leveraging system logs, browser developer tools, and a solid understanding of the platform’s configuration options (like business rules, UI policies, data policies, and dictionary overrides) will empower you to ensure that your forms function flawlessly, leading to improved user satisfaction and operational efficiency.


Scroll to Top