Guidelines for using source control

  • Release version: Australia
  • Updated March 12, 2026
  • 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 Guidelines for using source control

    ServiceNow recommends using source control (Git) combined with the Application Repository as the preferred deployment method for custom scoped applications. System Update Sets remain an approved option, especially for quick operational changes, emergency hotfixes, or scenarios not suited to source control workflows.

    Show full answer Show less

    Key Features

    • Full change history: Git tracks detailed, auditable records of changes including author, timing, and rationale, supporting review and revert capabilities at the file level.
    • Branching and parallel development: Enables multiple developers to work on features simultaneously without conflicts.
    • Code review workflows: Pull requests enforce peer reviews to minimize errors and security risks before publishing changes.
    • Versioned releases: Tags and branches correlate to Application Repository versions, facilitating reliable rollbacks and hotfixes.
    • CI/CD integration: Supports external tools like Jenkins, GitHub Actions, and Azure DevOps to automate builds, testing, and deployments via the ServiceNow SDK and CLI.

    When to Use System Update Sets

    System Update Sets are appropriate for:

    • Global-scope configurations.
    • Emergency hotfixes requiring fast deployment.
    • Organizations transitioning from legacy development practices.
    • Changes to ServiceNow Store or plugin applications incompatible with Application Repository workflows.

    Instance Scan checks should be used to validate System Update Sets before committing, and batching related update sets is recommended to reduce deployment complexity.

    Security Guidelines

    • Enforce least privilege: Use application-specific roles and configure ACLs with role evaluation first, followed by conditions and scripts for optimal security and performance.
    • Use deny-by-default: Keep the glide.sm.defaultmode property in Deny mode to restrict administrative access by default.
    • Run Instance Scan automatically: Detect empty ACLs, excessive permissions, and coding standard violations pre-production.
    • Protect cross-scope access: Deliberately configure cross-scope privileges to avoid overly open access.
    • Implement multi-factor authentication and IP restrictions: Require MFA for interactive deployment accounts and restrict service accounts by IP and scoped roles.
    • Audit everything: Regularly review permissions with Access Analyzer and forward logs to SIEM platforms for monitoring.
    • Separate data from code: Manage application data, reference data, and seed data through controlled processes outside Application Repository deployments.

    Deployment Method Decision Matrix

    Scenario Recommended Approach
    New custom scoped application Use source control (Git) + Application Repository + App Engine Management Center Pipelines and Deployments or ReleaseOps
    Global scope configuration changes Use System Update Sets with Instance Scan or Application Repository for global applications
    Emergency production hotfix Use System Update Sets for speed, then backport changes into source control immediately
    Citizen developer app from App Engine Studio Use App Engine Management Center Pipelines and Deployments with guided approval workflows
    Multi-team release coordination Use ReleaseOps with release trains and playbook validation

    Source control (Git) combined with the Application Repository is the preferred deployment method for custom scoped applications. Using System Update Sets is also an approved deployment mechanism for application development.

    Why use source control?

    Full change history
    Git provides a complete, auditable record of every change, such as who made it, when, and why, with the ability to use diff, review, and revert functions at the individual file level.
    Branching and parallel development
    Multiple developers can work on different features simultaneously without conflicting update sets.
    Code review workflows
    Pull requests and merge reviews enforce peer review before any change is published, reducing errors and security oversights.
    Versioned releases
    Tags and branches map directly to Application Repository versions, enabling reliable rollbacks and hotfix workflows.
    CI/CD integration
    External CI/CD tools such as Jenkins, GitHub Actions, and Azure DevOps can trigger builds, tests, and deployments using the ServiceNow SDK and CLI.

    When are System Update Sets appropriate?

    System Update Sets retain value for quick operational changes to the following:
    • Global-scope configurations.
    • Emergency hotfixes when the full source control pipeline would introduce unacceptable delay.
    • Organizations still transitioning from legacy development practices.
    • Changes to ServiceNow® Store or plugin applications where the Application Repository workflow doesn’t apply natively.
    Even in these scenarios, consider using Instance Scan checks on your System Update Sets before committing them, and batch related update sets to reduce deployment complexity.

    Security guidelines

    Enforce least privilege through access control lists (ACLs)
    Define custom application-specific roles rather than relying on broad system roles. Configure ACLs to use the evaluation order of roles first, then conditions, then scripts for optimal performance and security.
    Use deny-by-default
    The glide.sm.default_mode property should remain in Deny mode so that wildcard ACLs restrict access to admin-only by default.
    Run Instance Scan automatically
    Configure Instance Scan to run against System Update Sets and application deployments. This catches empty ACLs, overly permissive access, and coding standard violations before they reach production.
    Protect cross-scope access
    Configure application cross-scope access privileges deliberately. Do not default to open access for all scopes.
    Implement multi-factor authentication and IP restrictions
    All interactive accounts performing deployments should use multi-factor authentication. Service accounts for automated deployments should be restricted by IP range and have tightly scoped roles.
    Audit everything
    Use Access Analyzer to regularly review user, group, and role permissions. Forward deployment logs and Access Control activity to your SIEM platform for monitoring.
    Separate data from code
    Application data records are not included in Application Repository deployments. Manage reference data and seed data through separate, controlled processes with appropriate data classification.

    Deployment method decision matrix

    The following table shows the scenario and recommended deployment approach:

    Table 1. Deployment method approach
    Scenario Recommended approach
    New custom scoped application Use source control + Application Repository + App Engine Management Center Pipelines and Deployments, or ReleaseOps.
    Global scope configuration changes Use System Update Sets with Instance Scan or global application using the Application Repository.
    Emergency production hotfix Use System Update Sets for speed and back port into source control (Git) immediately after.
    Citizen developer app from App Engine Studio Use App Engine Management Center Pipelines and Deployments with a guided approval workflow.
    Multi-team release coordination: Use ReleaseOps with release trains and playbook validation.