OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Platform Health Check: Prepare the 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. Preparation should give the reviewer enough context to explain what was examined and the owner enough evidence to decide what happens next.

For ServiceNow platform owners preparing for a health check, audit, upgrade, or improvement decision..

ServiceNow platform health checkServiceNow health checkplatform readiness
Discuss this ServiceNow topic

Guide map

Gathering the evidence a health check needs

Define the review question and boundary

A health check needs one stated question, such as whether the platform is safe to upgrade, and a clear edge on what the review will and will not examine.

Gather configuration and ownership context

Collect the current configuration notes and the names of the people who own each area before the review starts, so findings can be assigned on the day.

Trace integrations, data, access, and performance

Start the health check with a list of every integration and the data it moves, then follow each one through access settings and the response times users actually see.

The practical framework

Prepare a ServiceNow platform health check with scope, ownership, configuration, integrations, access, data, performance, testing, risks, and decisions.

Start with the decision, not a request for every available export. A review for upgrade readiness may need different evidence from a review of access or workflow performance.

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.

The ServiceNow health-check and audit route is the relevant internal destination for a structured platform review.

Avoid calling a partial review a complete platform health assessment. A clear boundary makes the result more honest and actionable.

Gather configuration and ownership context

Explain the purpose and owner of applications, flows, scripts, tables, roles, reports, notifications, customisations, and scheduled work. Identify items that have no current owner or depend on undocumented knowledge.

The ServiceNow technical-debt review route provides an internal path when maintainability and ownership are central to the review.

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.

The ServiceNow integration and data route is the appropriate internal destination when the review includes source authority, mapping, or integration health.

The ServiceNow access-controls route gives the reader an internal path for role and visibility review.

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. Do not use a general best-practice statement as though it were 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.

The ServiceNow continuous-improvement route provides an internal path for turning findings into an owned improvement cycle.

Common questions

Questions teams ask about a platform health check

Is a health check just a configuration inventory?

No. An inventory identifies objects. A health check interprets purpose, ownership, dependency, data, access, performance, supportability, evidence, and the decision each finding requires.

What should happen after findings are recorded?

Assign an accountable owner, record the decision, sequence action, preserve evidence, and set a review point. Findings should change an operating or delivery decision rather than remain a report with no next step.

The research-grounded boundary

For ServiceNow platform health check work, the operating questions are which service or decision the platform affects, who owns the outcome, and what evidence supports it. A finding that cannot name its owner is not ready for a decision. For platform health check readiness, the final test is whether another responsible person can reproduce the decision from the retained record.

Work backwards from the decision the review must answer

Readiness for a health check is less about having data than about knowing which decision the data will serve. An owner preparing for an upgrade needs evidence about customizations, plugins, integrations and test coverage. An owner preparing for an audit needs evidence about access, change records and data handling. An owner who wants to cut cost needs evidence about scheduled jobs, unused applications and license use. Each decision pulls a different set of evidence, and a pack built to satisfy all three often satisfies none of them well.

Write the decision as a single sentence before anyone exports anything. For example: should the team upgrade in the next planning cycle, or defer until the custom application is retired? That sentence tells the reviewer which findings are relevant, and it gives the owner a clear test for whether the review has answered the question.

Match each evidence type to a source and a skeptic

The table lists evidence families that many platform reviews need, with the question each one answers and the check that stops it being taken at face value. The last column is the one that matters most, because exports are easy to produce and easy to misread.

Evidence familyQuestion it answersTypical sourceCheck before relying on it
Customization inventoryWhat has been changed from the standard, and by whom?Application and update records, scoped application listingsConfirm an owner exists for each customization, not just a creator
Integration mapWhich external systems depend on the instance, and how?Integration configuration and recent error historyCompare against what the integration owners believe is connected
Access reviewWho can change what, and is that still appropriate?Role and group assignments with recent activityAsk whether any privileged role has a current, named holder
Scheduled workWhich background jobs run, and do they still matter?Scheduled job listing with last run resultsCheck that a job which ran successfully still produces a useful outcome
Test evidenceWould the team notice if a change broke something?Automated test results and recent release recordsConfirm the tests cover the business process, not only the code path

A job that succeeds every night and feeds a report nobody reads is a finding in its own right. The health check should record it as a question of purpose, not as a technical success.

A preparation order that avoids a late scramble

The preparation work is most efficient when it runs in a fixed order, because later evidence depends on earlier decisions about scope.

  1. Write the decision sentence and the review boundary, including the applications, environments and period in scope.
  2. Name the owner who will accept the findings and the people who will be asked to explain each area.
  3. Collect the ownership list for custom applications, integrations and privileged roles, and mark any gaps before exporting anything else.
  4. Pull the evidence families in the table, each with the date it was taken and the person who took it.
  5. Hold a short walk-through with each area owner, to confirm what the export shows and what it misses.
  6. Freeze the evidence set with a clear version, so that later changes can be shown as new evidence rather than silent edits.

The walk-through in the fifth step is where the value sits. An owner who looks at an integration list and says the connection was retired last year has just saved the review from building a finding on a stale fact.

Common reasons readiness work stalls

Readiness work stalls for predictable reasons. Scope expands to cover every instance and every plugin, so nothing is finished in time. Exports are produced without a question, so the pack grows while the answer stays unclear. Owners are unavailable during the walk-through, so their areas are reviewed by someone who cannot confirm the facts. And evidence is captured in the middle of a migration or a major release, so the snapshot describes a platform that will not exist when the decision is made. If the instance is changing faster than the review can follow, postpone the snapshot and record the reason.

What to leave out of the evidence pack

An evidence pack should not contain credentials, personal data beyond what the question needs, or full copies of records where a count would answer the question. Redact at the point of export rather than in the final report, since a redacted report sitting beside an unredacted export is still an exposure. Keep the pack to the evidence the decision requires, and say in the boundary section what was deliberately excluded and why.

The governance material that defines who may approve each change also belongs in the pack. The platform governance charter guide is about who decides on architecture, access, data, applications and integrations.

When to wait before running a readiness review

Postpone the review if a major migration is underway, if the owner for the platform has just changed, or if the instance is about to receive a large batch of new applications. In each case the findings will describe a transitional state. Where an upgrade is the driver, the upgrade planning guide is about understanding what the organization depends on and how the team will respond if the result is not as expected.

How far back should the review look at activity?

Far enough to cover a full operating cycle for the business, including its periodic peaks, but not so far that changes made by people who have since left dominate the picture. The right window depends on how the service runs, so agree it with the owner rather than taking a default.

Can our own team run the readiness review without an outside reviewer?

Yes, provided the team that built the platform is not the only team that judges it. An internal review tends to miss findings that the builders stopped seeing long ago, so include someone from operations or security who did not design the changes under review.

Who should sign off the findings?

The accountable service owner, with the area owners named as having confirmed their sections. A sign-off by the technical lead alone shows that the build was checked, not that the service owner accepts the operating consequences.

Where do accepted findings get recorded?

Record them as accepted risk with the reason, the owner who accepted it and a review date. A finding that is neither fixed nor accepted keeps coming back in each review and erodes trust in the process.

Prepare the review with an outside perspective

If the decision in front of you is an upgrade, an audit or a cost review, a second view of the evidence pack can test whether the findings will hold. Contact OBLYTECH about a ServiceNow review. The ServiceNow health checks and audits page is the related service page.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

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

More from the blog

Related reading