Setting up dashboard policy profile

For 99% of the products, a requirement is to show the policy information in the dashboard. To achieve this without introducing product-specific components into the KASKO platform, the scope is limited to the app repository (i.e. plugin). This guide covers how to set up a basic summary screen and how to enable MTAs for it.

Adding policy profile screen to dashboard

Add summary screen

To start, we will need to create a summary screen specifically for the dashboard. In some cases, we might reuse the customer-facing summary screen (if all the information is there), but in most cases, we will need to set up a new screen.

TIP: Most apps use the path summary-admin for the dashboard-specific summary screen.

Example:

{
  "path": "summary-admin",
  "components": [
    {
      "type": "form",
      "config": {
        "components": [
          {
            "type": "summary-panel",
            "config": {
              "content_key": "flow.summary.policyholder.title",
              "components": [
                {
                  "type": "summary-panel-row",
                  "config": {
                    "content_key": {
                      "label": "flow.summary.policyholder.name.label",
                      "value": "flow.summary.policyholder.name.value"
                    },
                    "input_field": "first_name"
                  }
                },
                {
                  "type": "summary-panel-row",
                  "config": {
                    "content_key": {
                      "label": "flow.summary.policyholder.email.label",
                      "value": "flow.summary.policyholder.email.value"
                    },
                    "input_field": "email"
                  }
                }
              ]
            }
          }
        ]
      }
    }
  ]
}

Point to the summary screen

Next, we need to point the user to the new dashboard summary screen as soon as the app is opened. This can be achieved via conditional logic within the initial_screens config.

A flag called is_admin will always be set to true if the user is entering via the dashboard with required authentication credentials.

Example:

{
  "initial_screen": {
    "type": "jsonlogic",
    "schema": {
      "if": [
        {
          "===": [
            {
              "var": "flags.is_admin"
            },
            true
          ]
        },
        "summary-admin",
        "start"
      ]
    }
  }
}

Improve the styling (optional)

Lastly, we can improve the styling of the application that's being embedded within the dashboard.

This can be done by modifying the dashboard.css file within the application. See KASKO example app for working samples.

IMPORTANT: it is also required that dashboard_entry_points have been set up correctly in the .kasko directory of the build artifact. An example can be found in the KASKO example app.

MTA & Policy Edit

Mid-term adjustments (MTAs) give dashboard users the ability to modify quote data for a policy that has been purchased beforehand. Policy edit is the same, but for non pricing relevant fields (policy fields). However, these will work only given some specific requirements. These are listed below.

Requirements

1. must be an item product or pb product (old product-variants will not work)

2. must use v2+ quote-svc

3. must-have the dashboard policy profile screen set up correctly (see above)

4. must have MTA field definitions (see below)

Enabling MTAs

All it takes is to create proper field definitions for MTAs. These are quote_patch and policy_patch. Either of them can be skipped if there are no fields that can be modified in the given request.

When the field definitions have been set, the framework will know for which fields the "edit" button needs to be shown based on editable property.

Patch field definition must include all fields that should be sent to API.

• Fields that are not listed here, will be editable in UI and not sent to API;

• Fields that are listed here and marked as non-editable, will also be sent to API, but user will not be able to edit them.

Only validation in quote_patch fields will be evaluated so quote can have different validation for the same field.

{
  "quote_patch": [
    {
      "name": "duration",
      "path": "data",
      "validation": "required|string|in:P1Y,P2Y,P3Y",
      "editable": true
    },
    {
      "name": "dob",
      "path": "data",
      "validation": "required|date",
      "editable": false
    }
  ],
  "policy_patch": [
    {
      "name": "first_name",
      "path": "",
      "validation": "required|string|max:255",
      "editable": true
    },
    {
      "name": "last_name",
      "path": "",
      "validation": "required|string|max:255",
      "editable": true
    }
  ]
}

editable property can only be boolean value inside field definition, but inside manifest it is also possible to overwrite it with jsonlogic.

Manifest only:

{
  "schema": {
    "config": {
      "requests": [
        {
          "type": "quote_patch",
          "field_definition": {
            "quote_patch": [
              {
                "name": "duration",
                "path": "data",
                "validation": "",
                "editable": {
                  "type": "jsonlogic",
                  "schema": {
                    "!": {
                      "var": "active_policy.quote.customer_input.duration"
                    }
                  }
                }
              }
            ]
          }
        }
      ]
    }
  }
}

In example above, duration field will be disabled if policy aleady has duration set.

IMPORTANT: it is also necessary to change the next definition of all the screens where the MTA fields are. This is so that the framework would know where to navigate after the user changes his values and clicks the "next" button.

Testing locally

To test MTA & policy edit locally, just use snippet configuartion like so:

export const snippet = {
	config: {
		is_admin: true, // Must be enabled at all times
		is_mta: true,
		is_policy_edit: true,
		authorization_token: 'Bearer test',
		policy: {
			id: 'tpol_123',
		},
	},
};

This snippet config should be exported from local webapp integration response.js file.

Then open local webapp in browser with suffix /snippet. This will load snippet configuration you have defined.