Plan before you build

  • Release version: Xanadu
  • Updated August 1, 2024
  • 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 Plan before you build

    This guidance helps ServiceNow customers effectively plan application development by addressing key decisions and best practices before building their applications. It emphasizes the importance of understanding application scope, selecting appropriate instances for development, and making thoughtful naming choices to ensure smooth development, testing, and deployment.

    Show full answer Show less

    Application Scope

    • Applications are typically created in a private scope, which restricts access so only artifacts within the same scope can fully manage application data and logic.
    • Scoped applications support source control integration and delegated development, unlike globally scoped applications.
    • Use global scope only when:
      • The app must delete global data.
      • The app needs to alter access settings on multiple default tables.
      • The app requires APIs exclusive to the global scope, which cannot be accessed via passthrough script includes from a private scope.
    • Understanding scope is critical because it affects access, development methods, and integration options within your ServiceNow instance.

    Instance Selection

    • Proof of Concept (PoC) applications should be developed in separate instances such as sandboxes or Personal Developer Instances (PDIs) to isolate experimental work.
    • PDIs follow a naming convention like dev12345.service-now.com and are ideal for early-stage development.
    • Avoid importing PoC apps directly into organizational development instances due to namespace mismatches, which can cause integration issues.
    • Applications intended for production use should be built within the organization's official development instance to align with established testing and deployment processes.

    Naming Decisions

    • Application names influence the generated scope, which uniquely identifies application files and resources.
    • Scopes follow the pattern: x[company code][applicationname], with a maximum length of 18 characters.
    • Example: An app named "Legal Request" may have the scope xacmelegalreque.
    • Because all application artifacts inherit the scope, choose the name thoughtfully to avoid future complications.
    • Note that application names can be changed later if necessary.

    Essentially, an application is a digital program that supports user tasks. Some actions you take when building an application might be irreversible. Be aware of these actions and plan for them in advance.

    Application scope

    One of the first major decisions to make when creating an application is: Should the application be in a private scope or a global scope?

    By default, applications are created in their own private application scope. Applications in a private application scope restrict access to their application artifacts so only application artifacts in the same scope have full access to create, modify, remove, or run application data. Scoped applications can use source control integration and delegated development. Globally scoped applications cannot use delegated development.

    Create custom business applications in scope unless:
    • The application has to delete global data.
    • The application needs to change application access settings on multiple default tables to function.
    • The application needs to access APIs only available in the global scope. Creating a globally scoped passthrough script include would not be enough for this requirement.
    Note:
    Globally scoped passthrough is a script include created in a global scope that is accessible from the private scope. The passthrough gives access to a global API that is not accessible by default from a private application scope.

    For more information, see Application scope and Understanding Application Scope on the ServiceNow AI Platform (Whitepaper).

    Instance selection

    Proof of Concept (PoC) application builds can and should be built in a separate instance from a regular development instance. The instance can be a sandbox instance or a Personal Developer Instance (PDI) from the Developer Site. The PDI naming format is dev12345.service-now.com.

    If using an instance with a different scope namespace, rebuild the PoC applications in the organization’s development instance. Do not import the applications into the organization's development instance. The scoped namespace for the applications will not match the scoped namespace for the company’s development instance.

    Applications the organization intends to use (i.e. production apps) should be created in the organization’s developer instance, so the application can follow the organization’s testing and deployment process.

    Naming decisions

    The application name matters. ServiceNow suggests a scope based on the application’s name. Application file names are appended to the scope to uniquely identify application resources in an instance. Scope is in the format: x_[company code]_[application_name] with a maximum of 18 characters. For example, an application name Legal Request has a suggested scope of x_acme_legal_reque.

    All application files within the application inherit the scope, so carefully consider what the value should be. The application name can always be changed.