Policy 360 in Openkoda PAS: One View and Custom Actions

What is a Policy 360 View?

A customer rings about their home policy. To answer them, someone has to know what the policy covers, what it costs, whether anything is owed, whether a claim is running, and what has already been sent out. In a lot of insurers that is four systems and a copied reference number, and the caller hears typing.

A policy 360 view is the answer to that: one page per policy, carrying everything the record knows and everything a person is likely to do next.

Three things are worth separating before you read one, because they are usually spoken of as if they were the same thing:

The record - the policy itself, and everything filed against it: coverages, the insured property, invoices and payments, claims, documents, emails, the history of each period.
The view - the page that assembles all of that in one scroll, in the order someone on a call needs it: the numbers first, the detail underneath.
The actions - the toolbar at the top. Endorse, cancel, renew, file a claim, record a payment. These are not hard-wired into the page; each is a small workflow attached to the product, which is what makes the last section of this article possible at all.

Keeping the third one separate is the part people miss. If the actions on a record are configuration rather than code, then “we always email the documents when a customer asks” stops being a feature request and becomes an afternoon’s work by the person who wants it.

The whole thing is on video as well, if you would rather watch someone do it than read the steps. It covers the same fourteen steps in one pass; the written version below is the one to keep open in another window while you build your own.

How to Use a Policy 360 View and Add a Custom Action Button

The walkthrough below reads one in-force home policy end to end, then extends the page: a new Email documents to client action goes onto the toolbar, backed by a three-step workflow, and gets clicked. The first seven steps are for anyone who answers the phone; the last seven are for whoever configures the product.

Before you start, you will need: a product with at least one in-force policy on it, an email template and a document template on that product, and an account that can reach both the policy list and the Product Builder.

Step 1 - Find the Policy

Open Policies. The list is the book of business - every policy, with its insured, its product, its status, the term, the premium, the outstanding balance and whether a claim is open.

The Openkoda policy list showing 43 policies with insured, product, status, term, premium, balance and open claims — The book of business: every policy, with the insured, the product, the term, the premium, what is owed and whether a claim is open.

Search by the caller’s name rather than by the policy number. It is what the person on the phone actually gives you, and it is one field instead of sixteen characters of reference read out letter by letter.

The policy list filtered to one row by typing the insured's surname in the search box — Search by the caller's name rather than the policy number - it is what the person on the phone actually gives you.

Open the row. Everything from here to Step 7 is one page.

Step 2 - Read the Four Numbers at the Top

The KPI band answers the questions that get asked first, before anyone scrolls: the annual premium, the balance due, how many claims are open, and how many days until renewal.

The policy 360 KPI band: annual premium EUR 624, balance due EUR 240, one open claim, 344 days to renewal — The four answers an operator is asked for on a call, before any scrolling: premium, balance, open claims, days to renewal.

Two of those four are alarms rather than facts. A balance due that is not zero and a claim count that is not zero both mean the conversation is about to be longer, and it is worth knowing that in the first second rather than the first minute.

Step 3 - Check What is Actually Covered

Underneath sit the coverages, each with its limits and its deductible, and below them the property the policy is written on.

Coverages and limits - buildings, contents and property owner liability with their limits and deductibles - above the insured items table — What the policy covers, with each limit and deductible, and the property it covers underneath it.

This is the part a customer disputes, so read it as they would: a limit per coverage, a deductible per coverage, and an address that had better match the one they are standing in.

Step 4 - Read the Money

Then billing: the account, the plan, the status, every instalment with what has been paid and what is outstanding, and the payments that have already cleared.

The billing section: billing account and status, three invoices with amounts, balances and Record payment buttons, and the recent payments table — Every instalment, what is paid, what is outstanding - and a payment recorded from the row itself rather than in a billing system.

Note the button on each unpaid row. A customer who rings about a document very often ends the call by paying something, and the difference between recording that here and recording it in a separate insurance billing system is the difference between a call that ends and a call that gets called back.

Step 5 - The Claim, on the Same Page

Claims against the policy sit in the same scroll - no second system, no reference number to carry across. Under them, the policy’s own history: each period, its dates and its written premium.

The claims table showing one open water damage claim, above the policy lifecycle timeline — The claim sits on the policy, not in a second system - and under it the policy's own history, period by period.

Step 6 - Documents and Everything That Was Sent

Further down, every document generated against this record - certificates, declarations pages - each with its type, whether the customer may see it, and when it was produced. Beneath them, every email the system has sent about this policy.

The documents and communications panel: generated certificates and declarations pages with visibility and date, and below them the emails sent about this policy — Documents generated against the record, and the emails that carried them - filed together, on the policy.

Anything that arrives by other means - a signed form, a photograph, a surveyor’s report - is filed onto the policy from the same panel, with its type and its visibility set as it goes on.

The Add a document dialog with document type, visibility and a file chooser — Anything that arrives by other means - a signed form, a photograph, a surveyor's report - is filed onto the policy from here.

Visibility is the field to be deliberate about: it is what decides whether the customer sees the file in their own portal, and it is easier to set correctly now than to explain later.

Step 7 - The Action Bar

Back at the top, the toolbar: edit, endorse, cancel, renew, file a claim, record a payment, raise a submission or a quote.

The policy action bar: edit, endorse, cancel, renew, file a claim, record payment, submission, quote and a carrier confirmation action — The day's work as buttons. Note the last one - a custom action this product already carries, which is the clue that the bar is extensible.

Look at the last button. Request carrier confirmation is not a standard action of a policy administration system - it is one this product’s own team added, and it sits on the bar looking exactly like the ones that shipped. That is the whole of the second half of this article, already done once.

Step 8 - Start a Workflow on the Product

Say the team wants one more: email the policy documents to the client, on demand. Open the product in the Product Builder and go to its Workflows tab. The actions and the automations live together here - the lifecycle flow, the collections run, the carrier confirmation from Step 7. Most of what sits on this tab arrived with the product, which can itself be configured from a requirements document by the AI Product Builder.

The Workflows tab of the Openkoda Home product, listing the lifecycle, collections and carrier-confirmation workflows with their triggers, step counts and status — Actions live on the product, beside the workflows that already run it - so a new one is an ordinary piece of configuration, not a release.

New workflow offers the usual lifecycle templates and a blank canvas. An action of your own starts blank.

The New workflow menu open, offering lifecycle templates and a blank canvas — Templates for the usual lifecycle flows, and a blank canvas for an action of your own - which is what this one needs.

Name it for what it does, not for how it works: the name is what the next person sees in this list when they wonder where the button came from.

Step 9 - Drag Out Three Steps

An action needs three things: something that starts it, something it does, and an end. Drag them out of the palette - Button on a case, Send message, End.

The workflow editor with a palette of steps on the left and three nodes dropped on the canvas: button on a case, send message, and end — Three steps out of the palette: what starts it, what it does, where it ends. The palette is the whole vocabulary - no code in it anywhere.

The palette is worth a moment on its own. Everything an action can do is in it - issue a claim payment, charge a card, generate a document, give portal access, create a task, wait, branch - and none of it is written in a language. What you cannot express here, you cannot express by typing either, which is a fair trade for never editing code to change a button.

Step 10 - Make the First Step a Button on the Policy

Select the trigger. Two fields matter: the record type the button belongs on - Policy - and the label operators will read.

The properties panel for the button step, with Show button on set to Policy and the button label typed in — Two fields decide where the action appears and what it says: the record type it belongs on, and the label operators will read.

Write the label as an instruction to the person clicking it, not as a description of the mechanism. Email documents to client tells an operator what will happen; Run document workflow tells them what you built.

Step 11 - Make the Second Step Send the Mail

Select the message step. The channel is email, the template is the product’s own, and the recipient is the customer rather than a hard-coded address - which is what makes the same action correct on every policy of this product.

The properties panel for the message step: channel email, the product's policy-documents template, sent to the customer, with a certificate template attached — Who it goes to, which template it uses, and - the line that does the real work - a document template attached, rendered against this policy as it is sent.

Attach document from templates is the line that does the real work. It does not attach a file sitting somewhere; it renders that document template against whichever policy the button was pressed on, at the moment it is pressed, and attaches the result. The customer gets a certificate with their own numbers in it, and a copy is filed on the record. Building the template behind it is its own job, covered in creating insurance policy documents with customizable templates.

Step 12 - Wire It, Save It, Turn It On

Join the three steps in a line, save, and activate.

The three workflow steps wired in a line, with a banner confirming the workflow is now the live one for the product — Wired, saved, activated - and live for everyone on the team at that moment. No deployment, no release note.

Activation is the moment the button exists. Until then the workflow is a draft that no operator can see; after it, everyone working on this product has the action, with no release to schedule and nothing to restart.

Step 13 - Use the Action

Go back to any policy on that product. The toolbar now carries one more button, sitting among the actions that shipped with the system.

The same policy action bar as before, now carrying an Email documents to client button among the standard actions — The same bar as Step 7, with one more button on it - indistinguishable from the actions that shipped with the product.

One press runs the whole chain, and the answer comes back beside the button rather than in a notification somewhere else.

The action bar after the click, with a tick and the workflow's name confirming it ran — One click, and the answer comes back beside the button: the workflow ran.

Step 14 - Check What the Customer Got

A tick is a claim, not evidence. The Emails log is the evidence: the message sits at the top, addressed to the insured, filed against this policy, with an attachment on it.

The email log with the new policy-documents message at the top, addressed to the insured, marked sent, with an attachment count — Top of the email log: the message the button sent, against this policy, with one attachment on it.

Open it and check the two things that are actually worth checking: that the attachment is the document you meant, and that the subject and body came out with the policy’s own values in them rather than a placeholder that never got substituted.

The sent email showing recipient, the policy it is about, the template used, the attached certificate PDF and the message body — And the mail itself: addressed to the insured, filed against the policy, with the certificate generated for this record attached.

The same file is now on the policy’s own document list, in the panel from Step 6 - so the next person to open the record can see what this customer was sent, and when.

A policy 360 view earns its name in the first minute of a phone call: the numbers at the top, the cover, the money, the claim and the paperwork in one scroll, with no second system to open.

But the part worth taking away is the toolbar. When the actions on a record are configuration rather than code, the distance between “we do this by hand every week” and “there is a button for it” is three steps on a canvas and an afternoon, and the person who noticed the problem is the person who can fix it.