ServiceNow Now Platform and Development: Guides and Services

Understanding the Now Platform

ServiceNow’s Now Platform is an integrated suite of modules that help organisations manage IT operations, business processes, and digital transformation. Rather than standalone tools, the platform connects service delivery, asset management, change control, and process automation into a unified environment. Understanding how the modules relate helps you plan which capabilities to invest in first.

The platform is built around a common data model. Records like Incidents, Changes, and Configuration Items share underlying tables and relationships. This means that automating how these work together becomes possible, and reporting can connect data across what might otherwise be separate systems. The platform philosophy favours transparency and integration over isolated modules.

Core Modules and Their Relationships

The platform includes modules for different operational needs. Service Management covers incident response, service requests, and problem solving. Asset Management tracks hardware, software and contracts across your estate. Change Management governs how systems are modified. Each module has specific purposes, but they work together to give you a complete operational view.

Configuration Management provides the data backbone. Understanding what you own, how systems connect and what depends on what else is foundational. Once you know your estate, you can manage incidents more effectively, assess the impact of changes, and track compliance of assets. Many organisations build their first platform implementation around getting asset and configuration data right.

Platform Development and Customisation

Out-of-the-box ServiceNow covers most common scenarios. Where organisations differ—in process workflows, approval hierarchies, or specific terminology—the platform allows customisation. Development might mean configuring built-in options, writing scripts for automation, or building new tables and workflows specific to your business.

A key consideration is maintainability. Configurations that align with platform defaults stay easier to maintain over time and through platform upgrades. Heavy customisation can make upgrades complex and create dependencies on specialist staff. Successful organisations balance their unique needs with keeping enough standard configuration that they don’t become isolated.

Integration and Ecosystem

Most organisations eventually connect ServiceNow to other systems. HR data flows in to track employees and their assignments. Security tools send alerts into incident management. External service providers report status updates. The platform provides integration tools and APIs to make these connections efficient and reliable.

Planning integrations early prevents rework. Deciding which systems are sources of truth—HR is the source for employees, for example—prevents data conflicts. Establishing clear data ownership and update routines keeps integrations healthy over time. Early integration work often pays dividends in data quality and operational efficiency.

Module Structure and Navigation

The platform groups related modules into areas: The Now Platform is the foundation, and the IT Service Management application runs on it alongside IT Operations Management and other applications, Strategic Portfolio Management, GRC and other domains. Within each area, modules handle specific operational needs: Incident Management handles emergency response, Problem Management handles root cause analysis, Service Request Management handles user requests.

Understanding this structure helps teams navigate the platform confidently. Service desk staff work mostly in Incident and Request Management. Platform administrators manage configurations and users. Executives review portfolio and financial reports. Developers build automations and custom features. Clear role definitions prevent confusion about who does what.

Getting Started and Building Maturity

Starting typically means choosing your first area: many organisations begin with Service Management and Asset Management together. Once those are running smoothly, adding Change Management and Problem Management creates a more complete operational picture. Advanced capabilities like Strategic Portfolio Management, GRC or AIOps often come later, once the foundation is solid.

Building capability is gradual. Your first implementation handles basic scenarios with simple workflows. As your team gains confidence and your data quality improves, you can automate more complex situations, integrate more systems, and use data for better decisions. This staged approach reduces risk and lets your team learn sustainably.

Choosing where the platform program starts

A leader who inherits a ServiceNow estate, or who is about to buy one, usually faces the same question in different words: which part of the platform should carry the first real workload? The answer depends less on which modules sound most useful and more on where the organization already has accurate data, a named owner and a process that people agree on. Pick a starting area where those three things are true. A flawless automation built on a service catalog nobody maintains will often fail, and the platform will get the blame.

What the platform actually shares between modules

The benefit of the Now Platform is that records from different areas sit on a common foundation. Incidents, changes, problems and many configuration items are built on the same task-based design, so a relationship set up once can be read from several places. That also means a weak decision in one area spreads. If the company field on users is filled in three different ways, every module that reports by company will be wrong in three different ways. Design the shared reference data before any single module goes live, and the later modules will inherit clean relationships rather than workarounds.

A sequence for the first platform decisions

The early decisions set the pace for everything else. Work through them in this order, and do not start a build until the earlier steps have written answers.

1. Name the business owner of each starting area, and give that person authority to say no to requests that do not fit.
2. Agree the reference data that every module reads: locations, companies, departments, user roles and the service hierarchy.
3. Decide the environments and the promotion path. Most teams benefit from at least a development instance and a test instance before production, and they need to know which of them carry real personal data.
4. Choose the change and release route for configuration. Update sets and source control both work, but without a rule for which one applies, changes get lost.
5. Set the first success measure before the first build, so that nobody has to invent one after go-live.

Where platform programs drift

Drift rarely starts with a bad decision. It starts with a reasonable exception that nobody records. A team adds a custom table because the standard one is slightly wrong for them, a second team copies that table, and a year later nobody can tell which one feeds the reports. The same pattern appears with scripts that override standard behavior, with notifications that go to a personal mailbox, and with administrator accounts shared between contractors. Record every exception against one owner, with a date for review. Without that, the platform looks configured while its actual rules live in a handful of people’s heads.

Upgrades expose drift quickly. Customizations that were written against the default behavior of a feature can behave differently once the feature changes, and the cost of finding out depends on how many exceptions were never written down. A simple register of custom objects, with the owning team beside each one, is one of the cheapest controls a platform team can keep.

When not to extend the platform yet

Not every need should become a ServiceNow build. If the process itself is still disputed between two departments, the platform will only make the dispute faster. If the data source is an unmaintained spreadsheet, a build will import the spreadsheet’s errors with more confidence. In those cases, the better first move is a short process review and a data clean-up, after which the platform work has something stable to rest on. This is also the point where a platform team should say so openly to the business, rather than building a partial solution to protect a schedule.

Questions leaders ask about the platform

Do we need every module before we start?

No. Many estates begin with one area and add others only once the first has an owner, clean data and a review routine. Adding modules in parallel tends to multiply the reference data problems rather than solve them.

How do we know the platform is being used well?

Look for records that are created, closed and reported on without a manual export, and for teams who can explain their own queue without consulting an administrator. Usage that depends on one expert is a risk even when the numbers look healthy.

Who should own the platform roadmap?

A small group with business and technical representation should own it, with one person accountable for decisions. A roadmap owned only by the technical team tends to optimize for the platform rather than for the work it is meant to support.

Should custom tables always be avoided?

No, but each one needs a reason that survives an upgrade review. A custom table that holds data nothing else in the estate can express is a sound choice. A custom table that duplicates a standard one is usually a cost.

Next step

If the choice of starting area is still open, the sequence above can be tested against your own tools, data and ownership. The App Engine and low-code guides and the Flow Designer guides cover two of the areas in more depth.