What should be configured, extended, or built?
Trace requirements against the existing platform estate and select a supported, governed application boundary.
ServiceNow solution delivery
Build a governed application from requirement to handover.
Design, configure, and build ServiceNow applications that connect users, workflows, data, and integrations—then verify them through QA and UAT, prepare the release, and hand over the operating model and documentation.
Delivery decisions
Choose the right platform boundary before building.
How will the application work in operations?
Define users, roles, workflows, data, integrations, exceptions, reporting, security, and support responsibilities.
What evidence authorizes release?
Connect acceptance criteria to QA, UAT, accessibility, security, rollback, documentation, training, and handover.
Application delivery lifecycle
Carry the application from architecture through release and support.
A bounded prototype can validate a high-risk assumption first. When implementation proceeds, the same evidence becomes input to the application backlog, build, testing, release, and handover.
- Architecture
- Application boundary, roles, data, integrations, security, and lifecycle
- Build
- Configured and custom components, workflows, interfaces, and reporting
- Verification
- Code review, QA, UAT, accessibility, security, and operational acceptance
- Release
- Source control, transport, deployment, rollback, and authorization evidence
- Handover
- Documentation, training, support ownership, and improvement backlog
- DiscoverConfirm users, requirements, constraints, and outcomes
- ArchitectChoose the application boundary and delivery backlog
- BuildConfigure, develop, integrate, and document
- VerifyComplete QA, UAT, and release-readiness evidence
- ReleaseDeploy under authorization and hand over operations
Delivery work products
Keep requirements, build decisions, tests, and handover connected.
Work products are tailored to scope and may include the architecture decision, application backlog, configured components, source artifacts, test evidence, release plan, operating documentation, and training materials.
Architecture and backlog
Requirements map to platform components, ownership, acceptance criteria, dependencies, and planned releases.
Build and verification
Configuration and code are reviewed against QA, UAT, accessibility, security, and operational scenarios.
Release and handover
Deployment, rollback, documentation, training, support ownership, and improvement work are prepared together.
Prototype as a starting phase
Validate uncertain workflow behavior before broader implementation.
A bounded catalog and intake prototype may use test data in a non-production ServiceNow PDI. It is an illustrative design phase, not a customer deployment or production result. Production work begins only after the responsible owners approve data, governance, accessibility, security, testing, release, and operating conditions.
AI use: AI may assist discovery, requirements, documentation, and QA under human review. Production AI use requires separately approved data, governance, security, and testing.
Decision evidence
Inspect the proof gate before authorizing production planning.
Use the artifact to distinguish the demonstrated workflow concept from the evidence, control path, and owner review required for a client-specific implementation decision.
The evidence state, control path, and owner-reviewed proof gate are detailed in the full diagram.
Application-path decision
Choose reuse, extension, or a scoped application from evidence.
Platform and application owners can inspect the decision fork before creating a new delivery surface inside the platform.
Inspect the existing estate
Trace the requirement against current products, data, workflows, integrations, roles, controls, technical debt, ownership, and lifecycle commitments.
Reuse when the existing capability fits
Prefer configuration and established services when they satisfy the requirement without weakening product boundaries, ownership, or upgradeability.
Extend within an owned boundary
Add narrowly scoped workflow, data, or interface behavior only when the extension has clear owners, controls, tests, and lifecycle responsibilities.
Create a scoped application when separation is justified
Define the application boundary, users, data, integrations, security, exceptions, support model, and acceptance evidence before building.
Plan isolation and release
Keep synthetic or approved non-production data, source control, transport, testing, rollback, support, and production authorization explicit.
The application decision begins with the existing estate, chooses reuse or bounded extension where appropriate, justifies a scoped application only when separation is needed, and preserves non-production isolation through an authorized release plan.