Build form and business logic

  • Release version: Zurich
  • Updated July 31, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Build form and business logic

    Building form and business logic is a crucial step in designing ServiceNow applications. It involves creating rules that control what users see and interact with on forms (form logic) and defining how data behaves when entered or modified (business logic). This process enhances user productivity and data consistency within the platform.

    Show full answer Show less

    Best Practices for Scripting and Modifications

    • Assess Requirements: Determine if the logic is essential and check if ServiceNow’s no-code or low-code options can meet the need before scripting.
    • Use No-Code Tools: Leverage Flow Designer, Virtual Agent, and UI Policies to build logic with minimal or no code, which simplifies debugging and future upgrades.
    • When to Script: Scripting is appropriate for creating custom Flow Designer actions, Scripted REST APIs, logic within scoped applications (Script Includes), and Service Portal widget customizations.
    • Stay Current: Keep up with ServiceNow release notes and certifications to understand new no-code capabilities and platform enhancements.

    Modifying Baseline Artifacts

    Instead of copying and deactivating baseline artifacts—a practice that complicates maintenance and upgrades—edit the original artifact directly. The ServiceNow Upgrade Engine tracks changes and highlights skipped upgrades, providing better visibility into customizations and simplifying future version management.

    Form Logic

    Form logic controls the visibility, read-only status, and mandatory state of fields on a form, ensuring users only interact with relevant information. This targeted control improves user efficiency and data quality.

    Business Rules and Flow Designer

    • Business Rules: Server-side scripts executed during record CRUD operations to enforce business logic.
    • Flow Designer: A no-code/low-code AI-powered tool that enables process owners to automate approvals, tasks, notifications, and record operations using natural language, reducing the need for scripting.

    The next step in designing an application is to build logic. Logic includes form logic (what people can and cannot see/use on a form) and business logic (rules that govern what happens to data when it is entered).

    Agentic AI

    Create applications with help from agentic AI. For more information, see Agentic development on the ServiceNow AI Platform.

    Scripting and modifications

    Before writing any code, be aware of the impact on upgrades and the adoption of new ServiceNow features. Particular care should be taken when modifying baseline artifacts and processes.

    Consider the following before scripting:

    • Assess the requirement. Is the logic critical to the functioning of the app?
    • Determine if ServiceNow can be configured to fulfill the requirement without code.
    • Leverage options, such as Flow Designer, Virtual Agent, and UI Policies to take advantage of platform capabilities without writing code.
    • Low and no-code approaches to logic are easier to debug and upgrade.

    Examples of when scripting is appropriate:

    • Building Flow Designer actions
    • Creating a Scripted REST API
    • Creating logic for scoped applications in Script Includes
    • Customizing and creating widgets for Service Portal

    Evaluate the business requirement and consider a no-code route before using a scripted solution.

    Be aware of ServiceNow enhancements. For example, in the orlando release, Virtual Agent conversations have more no-code options than London. Read release notes and other publications. Get certified and stay current with your certifications.

    To better understand when to customize, review the Innovate at Scale Success Playbook on the Customer Success Center.

    Modifying default behavior

    In the past, one of the strategies used was to copy the artifact to update and to deactivate the original. The copy/deactivate approach is no longer recommended due to the following issues:

    • Developers cannot tell if a deactivated artifact was upgraded without research.
    • Two files, the original and the copy, need to be maintained. Maintenance doubles each time a customization is made.
    • With each release, the customized record becomes older.
      • Customers do not receive the enhancements included in a new release.
      • A new release may rely on the original record being updated.
      • Developers may make more changes to compensate for the original record being inactive.

    A script where only the Active flag is changed will be updated, but the script does not appear on the skipped list. With the copy and deactivate strategy, a developer has less visibility into customizations and cannot easily assess or revert to the baseline version.

    Rather than copying and deactivating the original artifact, edit the artifact directly. The ServiceNow Upgrade Engine will add the latest version to the version history and report that the artifact was skipped. Developers can see a new version is available with the upgrade.