Solutions

  • Products
  • Use Cases
  • Industries

Platform

  • REPORT
  • Gartner: ServiceNow a Leader
  • 2018 Enterprise High-Productivity Application Platform as a Service Magic Quadrant

Customers

  • SUCCESS CENTER
  • Your Strategic Resource
  • Discover best practices for every phase of your ServiceNow journey

Explore

  • WHY SERVICENOW
  • Thanks to you.
  • You're why we're #1 on the Forbes World's Most Innovative Companies list.

Define the development model

ServiceNow offers several technical options to meet demands for customization and avoid negative effects on platform stability and upgrade timelines. Scoped applications and other resources allow you to safely accommodate complex business demands without sacrificing speed of delivery or performance.

Key insights

  • Use scoped applications to build custom apps and limit your use of domain separation to a narrow set of use cases.
  • Use delegated development and source control to manage distributed development.

Provide design guidance to your teams

Give your local teams, regions, or lines of business design guidance on how to use ServiceNow capabilities to respond to customization demands. Be sure to include guidance on:

  • Mechanisms – Promote using scoped applications to build custom apps in restricted or encapsulated environments. Use domain separation when specific use cases mandate that you isolate data between entities.
  • Tools – Promote using delegated development, update sets, and source control to ensure consistency in custom app development.

Build scoped applications to reduce complexity

Custom applications in ServiceNow should be built in scope, because it ensures that an application has boundaries that:

  • Allow the system to uniquely identify application artifacts, like tables, properties, user roles, and public and private API definitions
  • Encapsulate the runtime code
  • Provide table‑level data access control

Application scoping protects applications by identifying and restricting access to application files and data. By default, all custom applications have a private scope that uniquely identifies them and their associated artifacts with a namespace identifier.

A scoped application can access and change its own tables and business logic, while other applications cannot without explicit permission. This ensures custom apps do not interrupt core business services and that other applications do not interfere with a custom application’s normal functioning.

Scoped applications cannot access the privately marked artifacts of a different application in global scope, and they should be used for building new standalone apps. When you evaluate retained customizations, you should identify whether you can convert any of your global apps to scoped apps to reduce system complexity. Figure 4, outlines decision criteria for determining when global applications should be converted to scoped applications. Learn more about the APIs in Figure 4’s decision tree on the ServiceNow Developer Portal.

Figure 4: Deciding between global and scoped applications

 

Converting retained global apps to scoped apps

Be sure you use scoped applications where possible to reduce complexity and maintain a controlled, distributed development.

 

Customization and domain separation

Organizations typically implement domain separation for one of these two reasons:

  • The ServiceNow implementation is overseen by managed service providers.
  • The implementation spans multiple, independent legal entities.

With domain separation, you can separate ServiceNow data, processes, and administrative tasks into logically defined domains. You can share some global properties, data, and processes across all domains, but individual domains may have customized process definitions (and associated rules and policies) and user interfaces.

Most commonly, domain separation is implemented for managed service providers required to isolate data between legally separate entities. Domain separation should not be used as a method for containing complex customizations, except with the narrow use cases defined in Table 3.

In an implementation with a domain separation model, business‑smart customization should include a review of the customization built into both global scope and individual domains.

Converting retained global apps to scoped apps

For global apps you need to convert to scoped apps, the project team should:

  1. Create a copy of the application on another instance (made easier if the organization elects to stand up a new instance to remove or remediate customization, as defined in Stage 2).
  2. Create new scope.
  3. Copy the artifacts in scope.
  4. Deactivate the artifacts in global scope.

 

Planning the update set process
  1. Ensure that both instances are the same version.
  2. Determine the customizations to make in a single update set.
  3. Ensure all the base system records have matching sys_id fields.
  4. Identify a common path for update sets to move across instances and maintain that model.
  5. Plan when you will commit the update set to production.
  6. Make sure update set names are clear.
  7. Ensure you understand how update sets work.
  8. Before you make any customizations, double-check that you selected the correct update set.
Converting retained global apps to scoped apps

For global apps you need to convert to scoped apps, the project team should:

  1. Create a copy of the application on another instance (made easier if the organization elects to stand up a new instance to remove or remediate customization, as defined in Stage 2).
  2. Create new scope.
  3. Copy the artifacts in scope.
  4. Deactivate the artifacts in global scope.

 

Planning the update set process
  1. Ensure that both instances are the same version.
  2. Determine the customizations to make in a single update set.
  3. Ensure all the base system records have matching sys_id fields.
  4. Identify a common path for update sets to move across instances and maintain that model.
  5. Plan when you will commit the update set to production.
  6. Make sure update set names are clear.
  7. Ensure you understand how update sets work.
  8. Before you make any customizations, double-check that you selected the correct update set.

Table 3: Use cases for domain separation

 

Manage your custom application’s development and release

Larger or more complex organizations—especially those using multiple production instances—present some risk of inconsistency when implementing or maintaining customization best practices due to lapses in governance or failure to use available tools. ServiceNow offers several options to ensure consistent and efficient implementation of custom applications within and across instances.

Use delegated development to support a distributed/decentralized implementation

Delegated development will help you balance scalability and maintain control over customization. It also allows non‑administrators to develop scoped applications on the Now Platform. (Note that delegated developers can work only on scoped applications, not on global applications, and do not have access to any global artifacts.) For each application, administrators can:

  • Grant non‑admin users the ability to develop applications
  • Specify which application file types the developer can access
  • Grant the developer access to security records and script fields
  • Remove a user or group as a developer

Especially in a more decentralized organization (or an organization with multiple lines of business), delegated development lets ServiceNow administrators maintain effective governance and control over customization without compromising scalability. Delegated developers can build scoped applications, but ServiceNow administrators can reserve review and publication rights. Note: This will no longer be the case in the London release.

Additionally, developer permissions are application specific, so ServiceNow administrators set permissions for each application. A developer who, for example, has permission to access file types for one application does not necessarily have any permissions for another application.

Table 4: Delegated developer roles

 

Use source control to support consistency in development

Source control lets developers integrate with a GIT source control repository to save and manage multiple versions of a scoped application from a sub‑production instance. You can use source control to share apps across development instances while ensuring each instance remains independent. Developers use separate instances to work on different features, applications, or product releases at the same time, but they can share code between these instances and resolve collisions throughout the development process. Source control allows for more distributed development while ensuring the changes are effectively managed in development.

 

Use update sets to store customized changes across applications

An update set is a group of customizations you can move from one instance to another when you publish global applications only.

You can also use update sets to:

  • Store changes to a baseline or installed application
  • Store and apply a particular version of an application
  • Deploy changes to installed applications across multiple instances

Keep in mind that you should not use update sets to install scoped applications across instances. Instead, publish scoped applications to the application repository.

While you can use update sets to govern the deployment of a uniform set of changes or customizations to installed applications across instances, source control can be used to share or install custom applications across instances—and allow for more distributed development.

Planning the update set process

Use the application repository

Use the application repository to install custom applications across instances or when you want to deploy completed applications to end users. You can also use it to manage update sets automatically so any updates made across instances are made to the latest application version only.

Table 5 brings together a single‑page view of definitions for recommended development mechanisms, management tools, and deployment methods. Governance bodies like the design board can use this as a starting point to communicate recommended development standards to the local level.

Table 5: Development mechanisms, tools for managing distributed development, and deployment methods

 

Testing

Custom applications, whether scoped or global, should not be deployed without a comprehensive test plan for functionality and integrations (where applicable). You should test both before deployment as well as before and after an instance upgrade to evaluate any effects an upgrade may have on a custom application, particularly for global applications. Your testing should rely on a set of detailed test scripts you use consistently to evaluate functionality.

With the ServiceNow Automated Testing Framework, available in Istanbul, ServiceNow administrators as well as application creators can build tests for new custom applications with little or no scripting to ensure that individual custom applications can work effectively within the instance. Your governance guidelines for customization should include directions for testing using the Automated Testing Framework, as applicable, or alternatives.

After upgrading, testers should track any defects or deviations from the pre‑upgrade testing results for a custom application. Defect tracking can help identify root causes and create fixes. When a fix is identified, capture the fix in a single update set. The resulting update sets hold the cumulative fixes you should apply to the production instance.

Expert Tip

EXPERT TIP

Promote a consistent view of best practices for development across a federated governance model.

Explore additional phases

Plan

You want to be sure everything is in place for a smooth, successful deployment.

Deploy

You want to be sure you’re following best practices during implementation.

Optimize

You’re up and running and want to get the most from your investment.

Extend

You’re ready to extend ServiceNow into other areas of your enterprise.

Thank You

Thank you for submitting your request. A ServiceNow representative will be in contact within 48 hours.

form close button

Contact Us

I agree to receive emails from ServiceNow about product, services, and events. I can unsubscribe from any email if I wish.