How to Create Your Own Customizable Insurance Dashboards in Openkoda PAS

What Makes a Good Insurance Dashboard?

Most dashboards in insurance software are decoration. They are built once by whoever installed the system, they show what that person assumed a manager wants, and within a month everybody has gone back to running the same three exports into a spreadsheet.

The ones people actually use have three properties, and none of them is about the charts:

They belong to a desk, not to the company. “Billing desk” and “underwriting morning check” are dashboards. “Executive overview” is usually wallpaper.
They carry work, not just numbers. A queue you can click into beats a count of the same records, every time.
They are cheap enough to change that the team can fix one rather than work around it.

That third one decides the other two. If a dashboard is configuration - pick a widget, point it at an entity, drop it on a grid - then the person who knows what the desk needs can build it in an afternoon. If it is a development ticket, you get the wallpaper.

So what does a good one actually look like on the page? It comes down to a handful of choices:

Name it after the job. Billing collections, underwriting morning check, renewals this week. If you cannot name the desk, you are building wallpaper.
Put a queue on it, not only counts. The tile people work from is a sorted, filtered list that clicks through to the record; the numbers go around it.
Drop any figure that would not change what somebody does today. Those belong in a monthly report, where nobody has to skip past them every morning.
Give each viewer their own work. A personal task tile on a shared board lets one page serve a whole desk without becoming one person's.
Let it run live. A board that queries when the page opens beats a snapshot from last night's job, because a stale queue gets worked twice.

This walkthrough builds a billing dashboard tile by tile, then builds a second one by describing it in a sentence, and finally makes one the screen the team lands on.

Before you start, you will need: an account that can reach Dashboards and Reporting AI.

There is a video version if you would rather watch it. It is short; the written steps below are the ones worth having open while you build your own.

How to Build a Dashboard in Openkoda PAS

Step 1 - See Where Everyone Starts

Signing in does not open a menu. It opens the organization’s default dashboard.

The organization's default dashboard on sign-in, with quick actions, four counters, a chart of submissions by status and tables of premium by product — Signing in does not open a menu - it opens the organization's dashboard, with the numbers already on screen.

Worth noting before you build anything: whatever you make can become this. That raises the bar, because the first screen of the day should answer the first questions of the day.

Step 2 - Make the Report the Board Will Carry

Our billing board wants a breakdown that no standard widget produces, so make it first. Reporting AI takes the question in plain English and writes the query.

The Reporting AI page with a question typed in plain English and a generate button, beside a tab offering a SQL editor instead — Ask in plain English - the outstanding balance by product, biggest first. The SQL editor is there when you want it; most of the time you will not.

Be specific about ordering and rounding in the question itself. “Biggest first, rounded to whole numbers” is the difference between a report you can put on a wall and one somebody has to re-sort every time they read it.

The generated report showing outstanding balance per product, largest first, with an export button — Eleven rows against your own data, and nothing stored until you name it and save. That saved report is what the dashboard will embed.

Read the numbers before you save. A report that runs is not a report that is right, and this one is about to be embedded on a board the whole desk reads.

Step 3 - Start a Dashboard of Your Own

Every board the team has built lives in one list, with its widget count and the option to promote it.

The dashboard list showing each board with its widget count, who updated it and actions to edit, promote or delete, with one badged as default — Every board the team has built, with its widget count - and the one badged default is the screen everybody lands on.

The new dashboard dialog asking for a name and a line describing what the board is for — A name and a line about who it is for. Write that line properly - it is the only thing telling the next person what the board is meant to answer.

Step 4 - Everything Comes Out of One Picker

The add-widget dialog offering an entity list, a KPI tile, a chart, a saved AI report, a markdown note, my tasks and quick actions — Seven kinds of tile, and the whole vocabulary of a board: a list, a number, a chart, a saved report, a note, the viewer's own tasks, and buttons.

Seven is the entire vocabulary, and it is worth reading as a list of intentions rather than components: tell me a number, show me a shape, give me a queue, reuse an answer I already worked out, explain the page, show me my own work, let me start something.

Step 5 - A Number

The KPI widget editor with a title, the invoices entity, a SUM aggregation, the field to add up and financial formatting options — Three decisions make a number: what to count, how to aggregate it, and how to format it - here the sum of what is due, as money.

The formatting block is not cosmetic. A balance shown as 1190011 and a balance shown as EUR 1,190,011 are the same number and not the same tile. One gets read at a glance from across a desk; the other gets counted on fingers.

Step 6 - A Chart

The chart widget editor with the entity, the chart type, the field to group by and a top-N limit — A chart takes the same three decisions plus one: what to group by. A top-N limit is what keeps it readable.

Set the top-N limit deliberately. A bar chart grouped by a field with forty values is not a chart, it is a fringe, and the useful signal is nearly always in the first five bars.

Step 7 - A Working List, Not a Summary

The entity list widget editor with the invoices entity, a sort order, a page size and a status filter — The tile people actually work from: invoices, soonest due first, filtered to the ones still outstanding - a queue rather than a statistic.

This is the tile that decides whether the dashboard gets used. A number tells somebody there is work; a sorted, filtered list is the work, and it clicks through to the record. Sort by the field that decides priority, page it small enough to fit, and filter out everything already dealt with.

Step 8 - Reuse the Report, and Add Buttons

The saved report from Step 2 embeds directly, live, with nothing rebuilt on the board. And quick actions give the page somewhere to go.

The quick actions widget editor, each row a label and the internal path it links to — Quick actions are a label and a path each. They are what turn a board from something you read into somewhere you start work.

A board with a “New submission” button on it is a starting point for the day. A board without one is a report you look at before opening the thing you were going to open anyway.

Step 9 - Arrange It

The dashboard in edit mode, every tile added but stacked one per row, each carrying a drag handle and a remove button — Every tile added, none of them placed: in edit mode each one carries a drag handle, and the grid is twelve columns wide.

Tiles are dragged where you want them and sized to the space they need. The arrangement saves with the dashboard, so everybody opening it sees the same page, which matters more than it sounds when two people are talking about “the chart on the left”.

The finished billing dashboard: a heading note, a chart of invoices by status, the outstanding balance, quick action buttons, the collections worklist and the viewer's own tasks — The finished board: what it is for, the mix, the number, the buttons, the queue, and the viewer's own work - one page for one desk.

One tile behaves differently from the rest. My tasks shows the viewer’s own work, not the team’s, so the same board shows each person a different list. That is what lets one dashboard serve a desk rather than a person.

Step 10 - Or Describe the Board Instead

You do not have to place any of that by hand.

The generate-with-AI dialog with a paragraph describing who the dashboard is for and what they care about — Instead of placing tiles one by one, describe the job: who it is for, and what they need to see first.

Describe the role and the questions, not the widgets. “A morning check for an underwriting manager: how much new business is in flight, submissions by status, the referrals waiting on a decision” says what the board is for, and lets the layout follow from that.

The generated underwriting dashboard open in the builder, with three counters, two charts, a priority breakdown and a referrals list — What comes back is not a picture or a suggestion - it is a real layout in the builder, configured and placed, and still unsaved until you say so.

The important words are in the builder. Every tile it produced is an ordinary widget you can open, re-point, resize or delete, so the draft is a starting point rather than a black box, and nothing is stored until you save it.

Step 11 - Make It the Home Screen

The billing dashboard badged as default, which is what the team now sees on signing in — One click makes a board the default, and it becomes what the team sees when they sign in - live as of the moment they open it.

Two things are worth knowing before you promote one. Every widget only ever queries your own organization’s data, so a dashboard cannot leak across tenants. And each one runs when the page opens, so what people see is current rather than a snapshot from last night’s job.

The interesting thing about a dashboard builder is not what it can draw. It is who is allowed to use it. When a board is seven kinds of tile on a twelve-column grid, the billing supervisor can build the billing desk’s screen, and fix it next month when the process changes, without a ticket, a release or a conversation about priorities.

And when even that is too much, describing the desk in a sentence gets you a real layout to adjust rather than a mock-up to argue about. Either way, what goes away is the queue between noticing what a team needs on screen and putting it there.