Skip to content

Post-Installation Verification

Applies to: All subscriptions

Purpose

Prove the installation works. Not that it started — that it works. Complifly has several failure modes that produce a healthy-looking system, and this checklist is built specifically to catch them before a user does.

Audience

Implementation engineers and system administrators completing an installation or an upgrade. Also the customer's acceptance sign-off.

Prerequisites

  • All installation steps complete
  • Configuration applied, including provider credentials
  • At least one administrator account created
  • A sandbox provider environment available for the end-to-end test

Steps

Work the tiers in order. A failure at any tier makes the tiers above it unreliable, so stop and fix rather than continuing.

Tier 1 — the components are alive

# Check Method Pass condition
1.1 API responds Request the health path through the proxy HTTP 200 with a success body
1.2 API on the expected port Inspect listening ports on the host The configured port, not a fallback
1.3 Startup log clean Read the log from the start of startup No missing-object message; database connection established
1.4 Worker running Inspect the supervisor's process list Exactly one worker, running
1.5 Queue reachable, if used Connect from the application host Authenticated connection succeeds
1.6 Survives reboot Restart the host Both processes return unaided

The health endpoint is shallow by design. It confirms the process is answering; it does not confirm the database, the queue or the provider. Never treat it as a full health signal. See Health Endpoints.

Tier 2 — the database is correct

# Check Method Pass condition
2.1 Schema complete Application starts without naming a missing object Clean start
2.2 Security policies exist List the database's security policies One for every tenant-scoped table
2.3 Policies are enforced Sign in as tenant A and request a tenant B record Not found
2.4 Scope is server-derived Alter a client-supplied identifier in a request and repeat Result does not change
2.5 Migrations landed fully Compare migration counts against sys.partitions for affected tables Equal
2.6 Backup and restore proven Restore into a scratch environment and open it Completes, and data is present

Check 2.3 is the one that matters most and is skipped most often. It requires two identities, and creating the second one is the only reason people avoid it.

Tier 3 — the platform functions

# Check Method Pass condition
3.1 Sign-in works Sign in as an administrator Reaches the landing screen
3.2 Password reset works Trigger a reset to a real mailbox Message delivered and the reset completes
3.3 User creation works Create a test user and sign in as them Succeeds
3.4 Permissions are enforced Sign in as a limited role and attempt a restricted action Refused or greyed out
3.5 Master data loads Load a small master data set Records appear and are correctly scoped
3.6 Background jobs run Submit a file upload The job completes rather than sitting queued
3.7 Provider connection works Run the connection test in the admin console Success
3.8 Notifications deliver Trigger a notification Delivered

Tier 4 — a document travels end to end

This is the only check that proves the installation as a whole. Use the sandbox provider environment.

# Step Pass condition
4.1 Ingest one document by the intended path Accepted, with an identifier returned
4.2 Inspect the mapped payload, on the API path Every field carries the intended value; dates in the expected format
4.3 Confirm it passed validation Not present in the Correction Cockpit
4.4 Confirm the route Status matches the expected route for the document type
4.5 Generate the IRN Status reaches generated, with a 64-character IRN and a signed QR stored
4.6 Print the document PDF renders; the QR code scans
4.7 Generate an e-Way Bill, if in scope Bill issued with a validity period
4.8 Confirm write-back, if enabled Event reaches delivered and the ERP shows the outcome

Tier 5 — deliberately break it

The tests above prove the happy path. These prove the system fails usefully, which is what determines whether support can diagnose anything later.

# Test Expected
5.1 Submit a document missing a required field Quarantined, with the failing field named — not a generic error
5.2 Submit the same document number twice Second one rejected as a duplicate
5.3 Submit a document for a GSTIN outside the credential's scope Rejected with an authorisation failure
5.4 Use an invalid credential Rejected as unauthorised
5.5 Point the provider at a wrong endpoint temporarily Government operations fail; local screens and Branded Print keep working. An uncached official NIC copy will not print — that is expected
5.6 Stop the worker and submit an upload Job queues rather than being lost; it processes when the worker returns

Test 5.5 is worth doing once per installation. It demonstrates to the customer, concretely, that a provider outage is a degradation rather than an outage — which is a claim they will otherwise have to take on trust.

Validation

The installation is signed off when:

Condition Evidence
All five tiers pass A completed checklist with results, dated and initialled
Tier 4 completed on the sandbox The document identifier and its IRN recorded
Tier 5 completed Each failure produced a specific, actionable message
No production credentials in a non-production environment Verified by attempting a call, not by reading configuration
Monitoring is live The checks in Monitoring and Health Checks are configured, not planned
Operations routine handed over The customer's operations owner has Daily Checks and knows who to contact

Retain the completed checklist. It is the baseline every future upgrade is verified against, and it is the fastest way to answer "did this ever work?" months later.

Troubleshooting

Symptom Tier Action
Health returns 200 but users report failures 1 The probe is shallow. Work Tier 2 and 3 checks; do not trust the probe alone
Application will not start, naming an object 2 Apply the named migration. See Migrations
Tenant A can see tenant B's data 2 Stop. This is a critical defect — escalate immediately, do not proceed to go-live
A migration's count and the storage count disagree 2 Half-applied migration. Restore and re-apply; do not continue
Users cannot reset passwords 3 Mail path blocked or misconfigured. Users will be locked out with no visible cause
Uploads sit queued forever 3 Worker down or queue unreachable. Restarting the API will not help
Provider connection test fails 3 Credentials, network path, or egress address allow-listing. See GSP Configuration
Document quarantined during the end-to-end test 4 Read the per-field messages. This is validation working, not a fault
Generation fails with a numbered error 4 Look it up in NIC Error Codes
Print fails while generation succeeded 4 Rendering dependencies or print configuration, never the government
Write-back never arrives 4 Check the flag first, then the outbox. Emission is not retrospective
A failure produces a generic message 5 Investigate before go-live. A vague failure now becomes an unresolvable ticket later
Local screens fail when the provider is unreachable 5 Unexpected. Reads should be served locally — capture details and escalate