ServiceNow App Engine Health Check

What a Health Check Engagement for App Engine Covers

An App Engine health check engagement with Oblytech assesses whether your custom applications built on the ServiceNow platform are healthy, maintainable and performing well. We review application architecture: are applications built following ServiceNow best practices or do they use shortcuts that create risk? We assess code quality: are there security vulnerabilities, performance problems or maintainability issues? We evaluate deployment processes: how are applications tested before release, who approves deployments and how are rollbacks handled if issues occur. We review application inventory: do you know all custom applications running on your platform, which teams maintain them and what is their support status.

Custom applications require ongoing support. Someone on your team must be responsible for each application. If the original developer leaves, knowledge transfer is important. Documentation of how the app works, what data it uses and how to modify it makes the app more maintainable.

Based on assessment, we recommend improvements to application quality, deployment practices and platform governance. The health check length depends on the scope of the platform and produces a roadmap for application modernization and governance improvements.

Typical Starting Problems and Development Practices

Many organisations begin building applications in ServiceNow without establishing governance. Developers create apps to solve immediate problems without considering maintainability or future support. Applications accumulate technical debt: shortcuts that worked initially but create problems as the app grows or is maintained by others. Code quality varies widely: some apps are well-structured, others are fragile and tightly coupled to specific data or configurations.

Another common problem is application sprawl. Multiple applications may provide similar functions, created separately by different teams. Users and support teams struggle to find the right application or do not know multiple applications exist for the same purpose. Applications with no clear owner are abandoned and become security and stability risks.

Code Quality and Security Assessment

We review application code for common issues: hardcoded credentials, missing input validation, SQL injection vulnerabilities, poor error handling and performance problems. We assess whether applications follow ServiceNow architectural patterns or have custom approaches that are fragile. We look for code complexity: are functions too long, are there high cyclomatic complexity metrics, is code maintainable by developers unfamiliar with the original author’s style.

We also assess security practices. Are sensitive operations logged and auditable? Are rate limits in place to prevent abuse? Are database queries optimized or do they risk performance problems under load? Do applications have proper authorization checks or could users access data they should not see? Security issues should be remediated immediately; code quality issues are prioritized by risk and impact.

Application Inventory and Ownership

We build a comprehensive inventory of custom applications running on your platform. For each, we document purpose, owner, maintenance status and dependencies on other applications or data. We identify orphaned applications: those with no clear owner or maintenance plan. We identify applications that duplicate functionality and recommend consolidation. We identify critical applications and ensure they have backup owners and documentation.

Ownership clarity is essential for support and maintenance. When a problem occurs, the support team must know who to contact. When the original developer leaves the organisation, continuity of maintenance is important. Applications should have documentation: what the app does, how to use it, what data it accesses and what to do if it breaks.

Deployment and Release Management

We assess how applications are deployed to production. Is there a formal release process with testing and approval? Or do developers deploy directly to production, risking data corruption or service interruption? We look for testing practices: do developers test locally before deploying, is there a staging environment for integration testing, are there automated tests that validate functionality. We assess rollback procedures: if a deployment causes problems, how quickly can it be reversed.

We also look at deployment frequency and batch size. Small frequent deployments are lower risk than large infrequent ones. If applications are deployed rarely, each deployment carries risk because changes are significant. If deployed frequently, each change is smaller and risk is distributed.

Platform Governance and Developer Enablement

We assess whether your platform is governed: are there standards developers are expected to follow, is code reviewed before deployment, are there architectural guidelines. We look for developer enablement: do developers have documentation and templates, is there a centre of excellence helping them follow best practices, are there common libraries they can reuse. Strong governance and enablement produce higher-quality applications and faster development.

We also assess platform readiness: are updates to ServiceNow applied regularly, are related applications tested when the platform is updated, are there known conflicts or incompatibilities that create problems.

Recommendations and Modernization Roadmap

Health check recommendations typically include establishing development standards, implementing code review and testing practices, consolidating or retiring duplicate applications and documenting ownership and support procedures. Quick wins include assigning owners to orphaned applications and documenting critical applications. Medium-term improvements include implementing automated testing and establishing a centre of excellence. Long-term improvements include modernizing legacy applications and establishing continuous delivery practices.

Who should run a health check and what they inherit

The reader for this section is usually the person who has just inherited a set of custom applications with no clear record of them. Often that is a platform owner whose predecessor has left, or an IT director who has found that a team built three apps on the platform last year without telling anyone. The review is built for that moment. Its first job is not to judge code. It is to establish what exists, who answers for each item and which items the business still depends on.

Before any code is read, the review needs a register with one row per application. Each row should carry the owning team, the named individual who can make a change, the tables and integrations the app touches, the last date someone deliberately changed it and whether anyone still uses it. Many organizations find at this stage that a supposedly critical application has no living owner. That finding alone can justify the exercise, because nothing else in the review can be acted on until someone is accountable. The App Engine governance model describes who should sign off that register.

Triage decisions for each application

Once the register exists, every application should land in one of a small number of outcomes. Trying to fix everything at once produces a long list nobody finishes. The table below is a practical way to make the call, using the same criteria the review applies to code and ownership.

What the register shows	Why it matters	Usual decision
Active, owned, recently maintained	The next change has a person who can approve it	Keep, and document the runbook
Active, owned, built on undocumented scripts	A platform upgrade may break behavior nobody can explain	Remediate before the next upgrade window
Two apps solving the same request in different teams	Users cannot tell which one is authoritative	Choose one, plan migration, retire the other
No owner, but users rely on it daily	Any fault will be handled by whoever is nearest	Assign an owner first, then review the code
No owner and no recent activity	It adds security surface without adding value	Retire through a controlled change

The orphaned-but-used row deserves the most attention. It is tempting to rewrite such an application straight away, but the owner has to be found first, because the person who approves a change to a live app is the person who will be paged when it fails. A rewrite without an owner simply creates a second orphan. Where the app also sits close to the boundary between scoped and global custom work, the ownership question tends to be harder than the technical one.

Review sequence for the first pass

A first pass should move in an order that keeps the risky findings visible early. Starting with code quality tends to bury the ownership gaps that matter most. The sequence below works as a default because each step gives the next one something to test against.

1. Confirm the inventory is complete by comparing the list against the platform’s own record of scoped applications and recently changed records, not against what teams say they built.
2. Attach a primary owner and a backup owner to each application, and record who can approve a production deployment.
3. Review access to each application’s data, including who can read and who can write, and whether any role grants more than the application’s purpose needs.
4. Look for embedded credentials, unvalidated input and background jobs running with elevated rights. These findings cannot wait for a roadmap.
5. Read the change records for the last several releases of each active application and note whether they were tested anywhere other than the developer’s own instance.
6. Write findings against the triage table and agree each decision with the owner, not on the owner’s behalf.

Signs the review is working and when to pause it

A health check has done its job when each active application has a named owner who has read its findings, and when the register is updated by the team rather than by the reviewer. A second sign is that developers ask about deployment approval before they build, instead of after. When those signs are missing months after the report, the review has yielded a document and not a change in how people work, and the roadmap needs an owner on the client side.

Some situations argue for waiting. If the platform is mid-upgrade, findings about compatibility will be stale within weeks. If the business is about to retire a family of applications, an in-depth code review is wasted effort, and a lighter ownership check is enough. A review run during a live incident also tends to produce rushed conclusions, so stabilise first. The managed support route is the better fit when the immediate need is keeping apps running rather than assessing them.

Questions teams raise before a health check

If the applications work today, why review them?

Working today describes the last deployment, not the next one. A review asks whether the next change can be made safely by someone other than its author, and whether a platform upgrade will break anything. A working application cannot answer either question on its own.

Should the original developers take part?

They should be interviewed, but their account should be checked against the register and the change records. Developers who have moved on are often the best source of design intent and the least reliable source of current ownership, so both views are needed.

What happens if a serious security defect turns up early?

It is handled outside the report. Findings that expose data or allow misuse are escalated straight away through the normal change route, with a short incident record, and are not held for a roadmap. The review continues with the remaining applications.

How is this different from an automated code scan?

A scan finds patterns in code. A health check also asks who owns the application, whether it duplicates another, how it is deployed and whether the business would notice if it disappeared. Automated results can feed the review, but they cannot decide whether an application should exist.

Next step for your application estate

If the register does not exist yet, that is the place to begin.