Claims and FNOL mode

This guide explains how to configure Claims / FNOL (First Notice of Loss) mode in the KASKO webapp framework.

Overview

Claims/FNOL mode is a dedicated flow for claim submissions. It differs from webapp/policy mode in request types, authentication, and pre-built screens.

Key characteristics:

• All claim fields use the claim request type.

• OTP login fields use the otp_fnol request type.

• Pre-built login screens are available for OTP authentication.

• Claim updates reuse claim fields with editable set (there is no claim_patch request type).

Enabling FNOL Mode

Enable FNOL mode via kdata:

https://webapp-url.com/?kdata=BASE64_ENCODED_JSON

Example kdata JSON:

{
  "app": "fnol"
}

You can also use claimsapp:

{
  "app": "claimsapp"
}

Request Types

Claims/FNOL Mode

Type	Description
claim	Submit claim details. ALL claim fields must use this type.
otp_fnol	OTP login fields for FNOL authentication.

Claim updates reuse claim fields with editable set.

Pre-built Login Screens

FNOL mode includes built-in login screens for OTP authentication:

• claim-login — email + policy ID input

• claim-login-sent — OTP sent confirmation

Built-in login fields (use otp_fnol request type):

• otp_email

• otp_policy_id

Authentication Flow

1. User enters email and policy ID on claim-login.

2. OTP is sent to email.

3. User enters OTP code.

4. On success, flags.is_fnol_user_logged_in becomes true.

5. active_policy.* namespace is populated.

6. User proceeds to claim form.

Namespaces

Claims/FNOL mode exposes the following namespaces:

• claim.* — claim response data

• active_policy.* — policy being claimed against

• input.* — user input fields

• flags.* — framework flags

Flags

Common FNOL flags:

• flags.is_fnol_user_logged_in — FNOL user authenticated

• flags.is_claim_edit — editing an existing claim

• flags.claim_draft_retrieved — draft claim loaded

Manifest Request Configuration

Enable otp_fnol and claim requests:

{
  "requests": [
    { "type": "otp_fnol" },
    { "type": "claim", "version": "v2" }
  ]
}

Field Definition Example

{
  "claim": [
    {
      "path": "data",
      "name": "incident_date",
      "validation": "required|iso_date"
    },
    {
      "path": "data",
      "name": "incident_description",
      "validation": "required|string|max:1000"
    }
  ]
}

Claim Form Example

{
  "path": "claim-details",
  "components": [
    {
      "type": "title",
      "config": { "content_key": "flow.claim_details.title" }
    },
    {
      "type": "form",
      "config": {
        "components": [
          {
            "type": "form-datepicker",
            "config": {
              "field_name": "data.incident_date",
              "content_key": {
                "label": "form.incident_date.label",
                "placeholder": "form.incident_date.placeholder"
              }
            }
          },
          {
            "type": "form-textarea",
            "config": {
              "field_name": "data.incident_description",
              "content_key": {
                "label": "form.incident_description.label",
                "placeholder": "form.incident_description.placeholder"
              }
            }
          }
        ],
        "footer_components": [
          { "type": "error-list" },
          { "type": "button-back" },
          {
            "type": "claim-update-button",
            "config": { "content_key": "flow.claim.submit" }
          }
        ]
      }
    }
  ],
  "next": "claim-confirmation"
}

Updating Existing Claims

Claim updates reuse the claim request type. To control editability, use editable on claim fields.

Example (backend definition with boolean editable):

{
  "claim": [
    {
      "path": "data",
      "name": "incident_date",
      "validation": "required|iso_date",
      "editable": true
    }
  ]
}

For conditional editability, override editable in the manifest request config using JsonLogic (manifest-only).

Tips

• Always include error-list in footer_components for form screens.

• Use required_requests on confirmation screens if you need to guarantee claim was submitted.

• Keep claim-specific content keys under flow.* and form.* namespaces for translations.