FireAndStorm Property Owner Portal Research Report

Full report

On this page

Executive summary

The accessible evidence for the current FireAndStorm demo is narrow but still useful. The demo landing page is a public “Choose Your Portal” screen that exposes four entry points: a Live Demo Workspace, Contractor Registration, Adjuster Registration, and Insurance Adjuster Login. The page explicitly states that the demo is read-only and that core transactional actions are unavailable, including create, update, delete, upload, approve, dispatch, invoice, payment, carrier submission, public packet links, and downloadable JSON. That means the public demo currently proves the existence of contractor- and adjuster-facing portal concepts, plus a seeded demo workspace, but it does not expose enough navigable content to verify deeper claim pages, field-level data models, or end-to-end workflow states. The planned production site at fireandstorm.com was not verifiable during this review because the fetch returned a 502-style failure.

Given that limitation, the safest conclusion is that a Property Owner portal should be added as a first-class role beside the existing Insurance Adjuster and Contractor roles, not as a light wrapper around either one. Owners need a camera-first, document-heavy, status-transparent experience: photo/video evidence capture, receipts and inventory support, inspection scheduling, estimate review, approval/dispute actions, and a clean payment/reimbursement view. That design direction is strongly supported by insurance-regulator and disaster-recovery guidance that emphasizes inventories, photos, receipts, status communication, and careful coordination before permanent repairs.

The recommended implementation approach is a shared claims core with portal-specific front ends, secured with OAuth 2.0, JWTs used conservatively and according to current best practices, RBAC plus object-level authorization checks, MFA / passkeys, secure file-upload controls, consistent audit logging, and PCI-scoped payment isolation if card payments are accepted. For insurance interoperability, align internal claim and document models to ACORD-style normalized structures even if the first release does not fully emit ACORD payloads externally.

Current demo findings

What was actually visible

The only reliably accessible FireAndStorm screen during this review was the public portal chooser. It brands the site as a Professional portal, titles the page Choose Your Portal, and describes three role-specific actions plus a live demo workspace. The copy indicates that the read-only demo workspace contains seeded sample claim workflows, that Contractor Registration is for onboarding using business contact details only, that Adjuster Registration is for read-only adjuster verification, and that Insurance Adjuster Login is for reviewing verified evidence read-only after verification.

The page also defines an unusually explicit “demo boundary.” It says the seeded demo pages are read-only and that the following are unavailable: create, update, delete, upload, approve, dispatch, invoice, payment, carrier submission, public packet links, and downloadable JSON. This is important because it implies the intended production system likely includes many of those behaviors, even though they were deliberately disabled in the public demo.

The contractor, adjuster registration, and adjuster login URLs were reachable as routes, but the crawler did not surface distinct forms or downstream content from them. In practice, that means the deeper route content was either the same shell content, client-rendered in a way the tool could not expose, or otherwise inaccessible. The production domain could not be validated because the fetch failed.

Inventory of visible features, roles, models, and workflows

What remains unspecified

The following elements could not be validated from the accessible demo and should therefore be treated as unspecified, not assumed: claim status taxonomy, actual dashboard design, forms and field lists, document categories, message center behavior, inspection scheduling UI, estimate data structure, invoice or payment flows, carrier integrations, admin roles, audit-log UX, mobile behavior, accessibility conformance, and actual API contracts. That is not a minor caveat; it materially shapes the design work because the Property Owner portal will need to establish some of these conventions rather than merely mirror verified existing ones.

Recommended Property Owner portal

A Property Owner portal should be designed for both residential and commercial owners, with the interface adapting to claim type rather than splitting into two separate systems initially. Regulator and disaster guidance consistently emphasize that claimants need to maintain inventories, capture photos and videos, save receipts, document structural damage and damaged contents, and coordinate repairs carefully with insurers and adjusters. Those recommendations map directly to owner-portal requirements.

Comprehensive feature set

Residential and commercial differences to handle in one portal

For residential owners, the portal should emphasize home inventory, room-by-room contents, livability, temporary housing / ALE documentation, and a simplified single-property experience. For commercial owners, it should add support for multiple buildings or suites, tenant/occupant coordination, business-contact delegates, rent-roll or income-impact attachments, and portfolio-style views. Those variants can share the same core claim, property, document, schedule, and payment abstractions if the data model is designed carefully from the start. FEMA, NFIP, and NAIC guidance already points to the importance of structured documentation, receipts, repair estimates, and staged claims handling; commercial claims add breadth, not a fundamentally different collaboration model.

Cross-portal operating model

Insurance guidance distinguishes the roles clearly enough to justify separate portal permissions. A carrier-side or independent insurance adjuster works for the insurer that is paying the claim, reviews what happened, inspects damage, and estimates payment. A public adjuster works for the claimant and should therefore be treated as a separate future role, not folded into the insurer-side adjuster portal. A contractor manages repair work. The property owner documents loss, coordinates access, reviews estimates, and receives repair/payment visibility. Those differences should drive the RBAC model, workflow initiators, and conflict rules.

Role comparison

Shared actions, fields, and audit requirements

Recommended sequence

The first recommended sequence is the core owner-adjuster-contractor intake flow. It makes the owner portal the primary evidence-collection surface while keeping authority boundaries intact for the adjuster and contractor. That pattern matches the regulator guidance that owners should document damage thoroughly, the adjuster should inspect and estimate, and repair activity should follow documented review.

sequenceDiagram
    autonumber
    participant O as Property Owner
    participant P as Owner Portal
    participant A as Insurance Adjuster Portal
    participant C as Contractor Portal
    participant X as Claims Core
    participant N as Notification Service
    participant L as Audit Log

    O->>P: Activate invite / sign in
    P->>X: Create owner session
    O->>P: Upload photos, receipts, notes
    P->>X: Store evidence + metadata
    X->>L: document.uploaded
    X->>A: Notify new evidence
    A->>X: Review claim + request inspection
    X->>L: schedule.proposed
    X->>N: Send owner scheduling request
    O->>P: Confirm appointment window
    P->>X: schedule.confirmed
    X->>L: schedule.confirmed
    A->>C: Assign contractor for field estimate
    C->>X: Submit inspection findings + estimate
    X->>L: estimate.submitted
    X->>A: Estimate ready for review
    X->>P: Owner can preview estimate status

The second recommended sequence covers estimate review, approval, dispute, repair, and payment. It intentionally separates owner consent from insurer authorization, which reduces ambiguity later if there is a pricing or scope disagreement.

sequenceDiagram
    autonumber
    participant O as Property Owner
    participant A as Insurance Adjuster
    participant C as Contractor
    participant X as Claims Core
    participant F as Finance/PSP
    participant L as Audit Log

    C->>X: Submit estimate revision
    X->>L: estimate.submitted
    A->>X: Approve estimate
    X->>L: estimate.reviewed[approved]
    X->>O: Notify owner estimate ready
    O->>X: Accept estimate OR request revision
    alt Owner accepts
        X->>L: owner.accepted_scope
        C->>X: Schedule repair + upload progress
        X->>L: work.updated
        C->>X: Submit invoice / completion package
        X->>L: invoice.submitted
        A->>X: Authorize payment
        X->>F: Trigger payout / reimbursement
        F-->>X: Payment result
        X->>L: payment.released
        X->>O: Payment/remittance visible
        X->>C: Contractor payment status visible
    else Owner disputes
        X->>L: dispute.opened
        A->>C: Request revision / clarification
        C->>X: Submit changed scope
        X->>L: estimate.submitted[revision]
    end

Integration architecture, schemas, endpoints, and security

Integration pattern

The cleanest architecture is a shared claims core with three portal front ends: Owner, Adjuster, and Contractor. If the current adjuster and contractor portals are already separate applications, keep them, but put a single API gateway / authorization layer in front of a normalized claims domain and publish business events from that domain through a message bus or webhook dispatcher. The demo’s explicit mention of future capabilities such as carrier submission and downloadable JSON is a good signal that integration-friendly design should be part of the first owner-portal release, not postponed.

A standardization layer should normalize core entities such as Claim, Property, Party, Document, Estimate, Invoice, Payment, Appointment, and AuditEvent, and then map them outward as needed to carriers, restoration vendors, and downstream finance systems. ACORD exists precisely to facilitate faster, more accurate data exchange and more efficient workflows through standard data structures and forms, so aligning internal schemas with ACORD-style semantics will reduce future integration friction even if the UI remains custom.

Security baseline

The security model should combine OAuth 2.0 for delegated authorization, JWTs only where they provide a clear interoperability benefit, RBAC, and claim-level object authorization checks on every API that accepts an identifier. That last point is essential because OWASP’s API Security guidance highlights broken object-level authorization and broken function-level authorization as leading API risks. JWTs should follow current best-practice guidance, which exists because insecure JWT handling remains common enough to require a formal best-current-practices update.

For interactive web and mobile clients, use Authorization Code + PKCE, short-lived access tokens, refresh-token rotation, device/session management, and step-up authentication for sensitive actions such as payment-detail changes, estimate acceptance, or delegated-access grants. NIST’s current digital-identity guidance continues to frame authentication, federation, and assurance levels as separate but coordinated design concerns; FIDO passkeys are an excellent option for phishing-resistant customer sign-in where supported, with TOTP or authenticator-app MFA as a fallback.

Uploads should be isolated in object storage, scanned, hashed, versioned, and served through time-limited URLs rather than web-root exposure. OWASP’s file-upload guidance explicitly recommends allow-listed extensions, validating actual file type instead of trusting Content-Type, generating application-controlled file names, imposing size limits, and limiting upload permission to authorized users.

Logging should be application-aware, not just infrastructure-level. Consistent business and security event logging is necessary for dispute handling, forensic review, and insurer/vendor accountability. OWASP’s logging guidance emphasizes that application logs should be consistent and always include security-relevant events; this maps directly to claim-status changes, permission changes, uploads, approvals, webhook deliveries, and payment operations.

If the portal accepts card payments directly, PCI DSS applies. The safer pattern is to push payment entry to a hosted or tokenized payment service provider page so the claims portal sees only tokens and payment status, not raw account data. PCI SSC describes PCI DSS as the baseline of technical and operational requirements designed to protect payment account data.

Privacy controls should include explicit purpose limitation, delegated-access consent, document-sharing consent, retention rules, and data minimization. NIST’s Privacy Framework is specifically intended to help organizations identify and manage privacy risk while building products and services.

Recommended schemas

Claim summary

{
  "claimId": "CLM-2026-004281",
  "propertyId": "PRP-009173",
  "ownerId": "OWN-22015",
  "claimType": "property_damage",
  "propertyUse": "residential",
  "lossDateUtc": "2026-06-03T18:40:00Z",
  "reportedDateUtc": "2026-06-04T01:12:14Z",
  "peril": "wind_hail",
  "status": "inspection_scheduled",
  "policy": {
    "policyNumberMasked": "HO3-*****-4821",
    "deductibleAmount": 2500.00,
    "currency": "USD"
  },
  "property": {
    "address1": "123 Example St",
    "city": "Chicago",
    "region": "IL",
    "postalCode": "60601",
    "country": "US"
  },
  "assignedAdjuster": {
    "partyId": "ADJ-7011",
    "displayName": "Assigned Adjuster",
    "contactChannel": "portal_message"
  },
  "nextActions": [
    "confirm_inspection_window",
    "upload_receipts_if_any"
  ]
}

Document

{
  "documentId": "DOC-778201",
  "claimId": "CLM-2026-004281",
  "uploadedByRole": "property_owner",
  "category": "damage_photo",
  "subcategory": "roof_exterior",
  "captureDateUtc": "2026-06-04T00:41:12Z",
  "fileNameOriginal": "IMG_4018.HEIC",
  "fileNameStored": "doc_778201.bin",
  "mimeTypeDetected": "image/heic",
  "sha256": "4f34d7f8d5d0fa6a9d8f6d3cbce2e8440d7c3d2f7b9b4f5a638e8c0b5f90c111",
  "sizeBytes": 4281888,
  "virusScanStatus": "clean",
  "visibility": {
    "owner": true,
    "adjuster": true,
    "contractor": true
  },
  "notes": "North slope shingles missing after storm."
}

Estimate review object

{
  "estimateId": "EST-44191",
  "claimId": "CLM-2026-004281",
  "contractorId": "CTR-1035",
  "version": 2,
  "currency": "USD",
  "lineItems": [
    {
      "lineId": "1",
      "code": "ROOF-REMOVE",
      "description": "Remove damaged shingles",
      "quantity": 24,
      "unit": "SQ",
      "unitPrice": 95.00,
      "amount": 2280.00
    },
    {
      "lineId": "2",
      "code": "ROOF-REPLACE",
      "description": "Install replacement architectural shingles",
      "quantity": 24,
      "unit": "SQ",
      "unitPrice": 245.00,
      "amount": 5880.00
    }
  ],
  "totals": {
    "subtotal": 8160.00,
    "tax": 0.00,
    "grandTotal": 8160.00
  },
  "review": {
    "adjusterDecision": "approved",
    "adjusterDecisionDateUtc": "2026-06-07T15:30:12Z",
    "ownerDecision": "pending",
    "ownerComment": null
  }
}

Webhook event

{
  "eventId": "evt_01JY1M8DFD4SMT08R5A9N4JQW1",
  "eventType": "claim.status.changed",
  "occurredAtUtc": "2026-06-07T15:31:02Z",
  "tenantId": "fireandstorm-prod",
  "claimId": "CLM-2026-004281",
  "data": {
    "previousStatus": "estimate_in_review",
    "newStatus": "awaiting_owner_approval",
    "actorRole": "insurance_adjuster",
    "actorId": "ADJ-7011"
  },
  "signature": {
    "alg": "hmac-sha256",
    "keyId": "whk_2026_01",
    "digest": "base64url-encoded-signature"
  }
}

Required endpoint set

UX direction and implementation roadmap

UX recommendations

Because the only reliably visible FireAndStorm screen is the public portal chooser, the cheapest and safest UX improvement is to extend that existing information architecture rather than invent a disconnected owner experience. Add Property Owner Portal as a peer entry on the chooser, with one sentence that explains it is for claim status, evidence upload, scheduling, estimates, and payments. Also separate read-only demo labeling from real portal labeling so users do not confuse seeded sample content with live claim activity. That recommendation is directly driven by the current chooser page design and its explicit read-only warning.

The owner dashboard should prioritize three things above everything else: status, required next action, and documents. A typical owner is not trying to “manage a workflow engine”; they are trying to answer, What happened? What do you still need from me? When is someone coming? What did you approve? Have I been paid? That aligns with the way regulator and disaster guidance frames post-loss recovery.

Annotated wireframe sketches

The accessible demo did not expose inner workspace pages, so a true annotated screenshot of deeper claim pages was not possible. The sketch below is therefore an annotated wireframe based on the visible portal chooser, followed by a proposed owner dashboard.

Current entry screen with recommended change

+----------------------------------------------------------------------------------+
| FireAndStorm Professional Portal                                                 |
| Choose Your Portal                                                               |
|----------------------------------------------------------------------------------|
| [ Live Demo Workspace ]  [ Property Owner Portal ]  [ Contractor Registration ]  |
|                         [ Adjuster Registration ] [ Adjuster Login ]             |
|----------------------------------------------------------------------------------|
| Existing demo copy says seeded demo pages are read-only.                         |
| Add owner copy here:                                                             |
| "Track claim status, upload photos/receipts, schedule inspections,               |
| review estimates, and monitor payments."                                         |
|----------------------------------------------------------------------------------|
| Demo boundary note should stay only on demo routes, not on production routes.    |
+----------------------------------------------------------------------------------+

Annotations

• Add Property Owner Portal as a first-class CTA beside existing roles.
• Keep Live Demo Workspace clearly labeled as sample/read-only.
• If adjuster/contractor onboarding is gated, owner activation should be invite-based from claim assignment.
• Avoid mixing “verification,” “registration,” and “login” language without a companion explanation of what each path is for.

Proposed owner dashboard

+----------------------------------------------------------------------------------+
| Claim CLM-2026-004281     123 Example St     Status: Awaiting Owner Approval     |
|----------------------------------------------------------------------------------|
| Next action: Review estimate v2 before Jun 10                                    |
| [Review Estimate] [Upload Receipt] [Message Adjuster] [Confirm Inspection]       |
|----------------------------------------------------------------------------------|
| Timeline                                                                          |
| Reported -> Evidence Uploaded -> Inspection Confirmed -> Estimate Approved -> ...|
|----------------------------------------------------------------------------------|
| Documents (12)         Appointments (1)         Payments                          |
| - Roof photos          - Tue Jun 11 13:00-15:00  - Deductible: $2,500            |
| - Temporary tarp rec.  - Contractor visit         - Issued: $0.00                |
| - Appliance serials    - Access notes             - Pending: Estimate decision    |
|----------------------------------------------------------------------------------|
| Messages                                                                        3 |
| Adjuster requested one more close-up roof image                                  |
+----------------------------------------------------------------------------------+

Annotations

• Put the one required action near the top, not buried in a work queue.
• Surface documents, appointments, and payments as equal peers.
• Make the timeline human-readable, not just status codes.
• Show deadlines only when they matter and make them accessible.
• On mobile, this becomes a vertical card layout with a fixed “Add Photo” action button.

Prioritized roadmap

A practical delivery sequence is: claims visibility first, collaboration second, approvals third, payments fourth. That order reduces dependency risk and gets the owner portal useful quickly without waiting for full carrier or finance integration. It also maps well to the current demo, which already hints at future payment, carrier submission, and JSON capabilities but does not expose them publicly yet.

Open questions and limitations

The most important limitation is that the accessible FireAndStorm demo did not expose its actual inner claim pages, so deeper inventory findings about dashboard widgets, data fields, and workflow states are necessarily incomplete. Contractor registration, adjuster registration, and adjuster login routes did not provide enough machine-readable content to verify distinct forms or screens. The production site at fireandstorm.com also could not be validated because the fetch failed.

Because of that, several areas remain open: the exact existing claim-state model, whether “Insurance Adjuster” means company adjuster only or includes independent adjusters, whether there is already an internal admin role, whether payment is insurer-direct or contractor-direct, whether carrier submission exists in a hidden environment already, and whether downloadable JSON is planned as an internal admin/export feature or customer-facing artifact. Those items should be resolved before finalizing the owner-portal contract and approval workflow.