OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow platform review practice

ServiceNow platform health-check readiness with useful evidence

A ServiceNow platform health check is useful when it answers a defined question about configuration, data, integrations, access, performance, testing, ownership, upgrade risk or supportability. OBLYTECH helps organisations prepare context for review and evidence for the next decision.

Discuss ServiceNow platform health-check readiness

Define the review question and boundary

State the services, applications, environments, tables, integrations, roles, workflows or period in scope. Record what is excluded and why. Define the owner who will accept findings and the decisions the review must enable. A partial review should not be described as a complete platform assessment.

Gather configuration and ownership context

Explain the purpose and owner of applications, flows, scripts, tables, roles, reports, notifications, customisations and scheduled work. Identify items with no current owner or that depend on undocumented knowledge. Ownership is evidence about supportability, not only an administrative field.

Trace integrations, data, access and performance

Map data sources, integrations, credentials, errors, identity, roles, permissions, service relationships and relevant performance or availability evidence. Separate observed behaviour from assumptions about cause. Keep the source and confidence of each observation visible.

Separate observations from recommendations

For each finding, state evidence, consequence, confidence, owner, dependency, decision and next action. Distinguish a configuration fact from an inference and a recommendation. A general best-practice statement is not automatically a finding about this platform.

Turn findings into owned decisions

Classify findings as retain with controls, correct, simplify, replace, retire, investigate or accept with review. Sequence work by service impact, risk, dependency, effort and readiness. Preserve the evidence that explains why the decision was made and when it should be revisited.

For the broader operating model, see ServiceNow platform operating model and governance. For control evidence, review ServiceNow risk assessment and control testing.

Discuss ServiceNow platform health-check readiness

Bring one review question, evidence gap or finding that is difficult to turn into a decision. OBLYTECH can help define scope, map ownership and separate observations from recommendations.

Start the conversation

Decide the question a health check must answer

A platform health check is only as useful as the question behind it. Some organizations commission one because an upgrade is approaching and they want to know what might break. Others want a view of technical debt before a budget round, or they suspect one integration is causing service problems. Each question points at different evidence, different people and a different length of review. Ask the sponsor to write the question in a single sentence before any scope is agreed. If two senior people write two different sentences, the review will try to answer both and will answer neither well.

Question a sponsor may askEvidence the review usually needsOutput the sponsor can act on
Is the platform ready for the next major release?Customization inventory, test coverage, integration list, deprecated features still in useA ranked list of items to fix, defer or accept before the upgrade window
Why do the same incidents keep returning?Incident and change history, integration error logs, ownership of the affected servicesA diagnosis of recurring causes with a named owner for each
Can we trust the configuration data?Discovery coverage, reconciliation results, ownership of configuration itemsA confidence statement by area and a remediation sequence
Is the instance safe to extend with new services?Access model, application boundaries, data sensitivityA list of changes needed before new work is added

Prepare people and access before the review starts

Much of the delay in a health check comes from waiting for access and answers rather than from analysis. Before the review starts, the sponsor should name a technical contact who can answer questions about the instance, a business contact for each service in scope, and a person who will accept the findings. The reviewer usually needs read access to configuration, logs and reports, and that request should be approved in advance. An export of selected configuration can be more suitable than broad access where the organization’s rules limit who may see certain data. Agree that rule at the start. A review that cannot see the data it needs will reach weaker conclusions than the sponsor expects.

Hold a short walk-through with the technical contact before detailed work begins. The aim is to learn where documentation is complete, where it exists only in someone’s memory and which areas the team already suspects. Those suspicions are useful, but they should be recorded as hypotheses until the review confirms them. The ServiceNow assessments and readiness page describes readiness as separating known conditions, open decisions, risks and out-of-scope work before a release is chosen.

What the review can and cannot establish

A health check reads the platform as it is on the day of the review. It can show that a scheduled job has failed repeatedly, that a table has grown without a retention rule, or that a set of roles grants more access than the business describes. It cannot prove that a process works from start to finish for every user, because that depends on testing real journeys. It also cannot set business priorities, which belong to the people who own the services. A report that presents a recommendation as if it were a finding has blurred that boundary, and the sponsor should ask the reviewer to keep the two apart.

Partial reviews are common and legitimate. A review that examines integrations and access but not reporting is valid if its first section says so. The risk lies in the summary, where a limited review can be read as a statement about the whole platform. Write the exclusions at the front of the report and repeat them in any executive summary.

How to read a findings register

When one arrives, check three things first. Does each finding point to evidence that someone else could retrieve? Is the confidence stated, and is it lower where the evidence is indirect? Does each row carry a decision category, such as correct, simplify, retire or accept with review, rather than a general suggestion to improve?

Expect a long list at first. A useful register groups related rows so that a single cause, such as an abandoned integration, appears once with its consequences rather than as a dozen separate complaints. A failing scheduled job that three teams depend on should be one finding with three listed consequences. That grouping is often the most valuable part of the work, because it shows where a few decisions would remove most of the problems.

Price drivers and the timetable

The cost and length of a health check depend mainly on the scope of the instance, the number of services and integrations in question, the state of the documentation, and how quickly access and answers are provided. An instance with clear ownership and current records is quicker to review than one where every answer must be reconstructed.

A sponsor can shorten the work without reducing its value by preparing three items in advance: the list of services and integrations in scope, the most recent change and incident history, and any existing architecture documentation, even if it is out of date. Missing items do not stop the review, but each one adds time because the reviewer must ask for it and wait.

Questions a sponsor should ask before agreeing scope

Is a health check the same as an audit?

No. An audit tests whether controls operate against a stated standard and usually gives assurance over a defined population. A health check looks at the condition of the platform and whether it can support the decisions ahead of it. Some organizations need both, and evidence from a health check can help prepare for an audit, but the two should not be confused in reporting.

Should the review start before the upgrade decision is made?

Often yes. A review that identifies the customizations most likely to conflict with a release gives the upgrade decision a factual basis. Starting after the decision has been taken leaves less room to change the plan. The performance and upgrade readiness page lists customizations, integrations, data, workflows and rollback among the things to connect when an upgrade is prepared.

Who should receive the report?

The accountable owner, the technical contact and the owner of each service named in a finding. A report sent only to the sponsor often produces actions that nobody with authority over the affected service has agreed to.

The next step after the register is accepted

A register becomes useful when each finding has an owner and a date for the decision it needs, even if that decision is to accept the risk for now. Review the register at a fixed point and record why each accepted item was accepted, so the reason is still available when the platform changes. Teams that skip this step often meet the same findings in the next review under different names. Where findings concern configuration data, the CMDB data quality and governance page connects quality rules to named owners, remediation work and exceptions.

To talk through a platform health check, start a conversation with one finding or evidence gap that has been hard to turn into a decision.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

Related guides

More in this section