Customer demos

Provision a populated demo tenant in minutes. Auto-destroy in 24 hours. Zero garbage left behind.

WASViking^® demos are not slide decks. The Partner Console provisions a fully populated tenant with synthetic data anchored to today's date, seeded across every product surface a prospect will ask about. Demos hard-destroy 24 hours after the scheduled presentation.

What a demo contains

The data is synthetic but realistic. Names, IPs, paths, and CVE refs look like a real environment. Dates lead with today and step back so the dashboard never looks stale.

Lifecycle

scheduled  ──▶  active  ──▶  destroyed
   │                            ▲
   └─ at presentation_at        │
                                └─ at presentation_at + 24h

Hourly Celery task partners.expire_demos runs the state transitions.

Quotas

When at quota, the New demo action surfaces a "destroy one first" message.

Login routing

Demo logins use a synthetic email under @demo.wasviking.com (null MX, never delivered). MFA codes and new-device alerts route to the partner operator's real email, not the synthetic mailbox, via the demo_email.resolve_auth_recipient safeguard.

If the routing cannot resolve (corrupted partner data), MFA mail is suppressed and logged as an operator alert. The platform refuses to let demo MFA leak to a real-looking address by accident.

Creating a demo

1. Demos → New demo.
2. Fill the form: prospect name, presentation time (datetime-local, tz-naive; the form writes a tz-aware ISO-8601 hidden field).
3. Check the demo-use attestation (24-hour synthetic showcase, no real prospect data, no real scans against prospect targets).
4. Submit.

Provisioning steps run inside a single Django transaction:

1. Internal organization flag set (is_internal=True, bypasses license).
2. Login user created with a temporary password.
3. Portal MySQL seed: 17 assets, 118 findings, 30 scans, etc.
4. Exploit Path Graph materializer runs on the demo org.
5. After commit, the API-side Mongo seed runs via the secured POST /api/v1/sensor/demo/seed/ endpoint, populating SSL, Edge, and scan-detail.

Credentials arrive at the partner operator's real email.

Destroying a demo

destroy_demo runs:

1. API-side purge first (deletes Mongo {organization_id, demo: true} docs).
2. Snapshot of partner-added Targets and ScanResults to PartnerAuditLog so traceability survives the hard delete.
3. Cascade-delete the demo Organization (drops portal MySQL).
4. Audit event demo.destroyed carries the snapshot.

Zero garbage left behind in either MySQL or Mongo.

Operator runbook

• reseed_demo <slug> re-runs the seed for an existing demo (portal + API). Refuses non-is_internal orgs.
• The Demos page shows current state, presentation time, and the audit trail.
• Failed provisioning leaves a clean state (the transaction rolls back).

Live activity on a demo

Demo orgs allow the prospect to add real targets and trigger real scans during the live walkthrough. Consent is enforced at Target creation (the regular platform policy), not by a separate partner attestation; duplicating it was tried and removed.

Activity from the live session is snapshotted into the destroy event so the partner can review what was done after the demo wraps.

Demo screenshot tile

Demo Targets get an inline-SVG mock screenshot data URI as thumbnail_url, not a broken S3 presigned URL. This is gated to is_internal=True orgs only. Real customer accounts are not affected.

Demo Targets are grouped under one Demo group so the Targets list shows "Demo" in the Group column.