How to Automate Insurance Processes in Openkoda PAS

Why the Claim Acknowledgment Is Worth Automating First

When a customer files a claim, the thing they remember is what happened in the next five minutes. Most insurers answer within a day or two, with a letter somebody assembled by copying a reference number out of one screen and into a Word file.

It is not difficult work. It is just work that happens hundreds of times, always at the point where the customer is most anxious, and always slightly differently depending on who does it.

It is also the best process to automate first, because it has all three pieces of a real one and none of the risk:

A document. The confirmation letter, in your wording, filled in from the claim.
A message. The email that carries it, in your branding, addressed to the right person.
A trigger. The moment the claim form arrives, and nothing else.

Nobody’s money moves and no decision is made, so the worst case of getting it wrong is a badly worded letter rather than a mispriced policy. And once those three pieces exist, every other automation on the product is the same shape.

This walkthrough builds all three and then files a claim as a customer to watch them fire.

Before you start, you will need: a product with a claim form, a Word file with your wording in it, and an account that can reach Document Automation, Email Templates and the Product Builder.

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

Part One: The Two Templates

Step 1 - Put the Letter in the Template Library

The document automation library listing Word templates, each bound to a record type and a product with a placeholder count and a version — A versioned library of Word templates, each bound to a record type and a product - and each showing how many placeholders it carries and how many are mapped.

Take visibility seriously. External is what lets the customer see the file in their portal, and it is much easier to set now than to explain later.

The upload form with the template named, the entity type set to Claim, the product scoped, visibility external and the document type left as Other — Four decisions before the file: what it is called, which record it is produced from, which product it belongs to, and whether the customer may see it.

And set the document type, even though it is optional. Leaving it as Other is why the generated file turns up later in this walkthrough named other.pdf rather than as a claim confirmation. It costs one dropdown now and saves every future reader of that claim a guess.

Step 2 - The Letter Is an Ordinary Word File

The claim confirmation letter in Word: normal layout and wording, with placeholders in curly braces wherever the claim's data belongs — Your layout, your wording - and a placeholder wherever the claim's own data belongs. Each one is named after the field it draws from.

The detail that makes the next step free: name each placeholder after the field it draws from. {##claim_number##}, {##policy.insured_party##}, {##cause_of_loss##}. The letter reads exactly the same to a human, and the system can bind it without being told.

Step 3 - Check What It Detected

The uploaded template page listing nine detected placeholders and a mapping table binding each to a field on the claim — Nine placeholders found and nine mapped - nothing left over. Naming each placeholder after its field is what makes that automatic.

Read the two numbers first: detected and mapped should be equal. If the file has ten placeholders and the page maps nine, one is misspelled or split by Word’s own formatting, and it is far cheaper to fix that in Word than to patch it here.

The configure mapping screen with one dropdown per placeholder, showing which field on the claim or its policy each one draws from — Every row stays editable: the policyholder comes from the policy's insured party, the cause of loss from the claim itself.

Note that the mapping follows the record outward. The claim knows its policy, so the policy’s insured party is reachable from a letter about the claim. That is what lets one template say everything a customer needs without anybody writing a query.

Step 4 - Write the Email That Carries It

The email template form pointed at the claim record and scoped to the product, with a subject line carrying a placeholder — The same library, but this one renders HTML. Point it at the claim, scope it to the product - and put the claim number in the subject.

A claim reference in the subject line is worth the thirty seconds. It is what lets the customer find the email again three weeks later, and what lets your team match a reply to a claim.

The email body in the visual editor: a branded responsive layout with a heading, body copy, a claim details block and a call-to-action button — The visual editor shows exactly what the customer receives - your colors and wording, with placeholders where the claim's data will go.

Keep the email and the letter saying the same thing in different depth. The email is the summary a person reads on a phone; the attached letter is the record they keep. Repeating the whole letter in the body makes the attachment pointless.

The insert-placeholder menu in the email editor, listing the fields a claim carries — You do not have to remember field names: the editor knows every field a claim carries and writes the token for you.

Part Two: The Workflow That Joins Them

Step 5 - Two Templates, Nothing Joining Them

The workflow editor with a palette of triggers, actions and control-flow steps beside a canvas holding the first node — Two templates and nothing joining them up. The palette is the vocabulary - triggers, actions, control flow - and this needs three steps.

Three steps is the whole flow: something that starts it, something it does, and an end.

Step 6 - Say Exactly When It Runs

The trigger's properties panel, set to run when the product's claim application form is submitted — The trigger watches for one specific form - so the flow runs the moment a customer files a claim on this product, and at no other time.

Bind the trigger to one named form, not to “a claim was created”. Claims get created by staff, by imports and by integrations; a customer filing the claim form is a different event, and it is the only one that should produce a “we have received your claim” email.

Step 7 - The Join: Attach the Document to the Message

The message step's properties: channel email, the confirmation template, addressed to the customer insured, with a document template attached — This is the join. The step picks the email template, addresses it to the insured, and attaches a document *from templates* - rendered against the claim on the way out.

Attach document from templates is the line that does the real work, and it is worth being precise about what it means. It does not attach a file sitting somewhere. It renders that Word template against whichever claim triggered the flow, at the moment it runs, and attaches the result. The customer gets a letter with their own claim in it, and a copy is filed on the record.

Note too that the recipient is a role, the customer insured on the policy, rather than an address. That is what makes one step correct for every claim the product will ever receive.

Step 8 - Validate, Save, Activate

The three steps wired in order, with a validation notice reporting no issues and a banner confirming the workflow is now live on the product — Wire the three in order, validate for loose ends, save and activate. From this moment it is live for every claim on the product.

Run the validation before activating. It catches the loose ends that are invisible on a canvas, a step wired to nothing or a trigger with no path to an end, and those are exactly the faults that otherwise show up as an email that never arrives.

Part Three: Watching It Fire

Step 9 - Now Be the Customer

The public claim form on the step asking about the damage: date, cause of loss, which cover it touches and a description — The customer's side: identify the policy, then the date, the cause - escape of water - the cover it touches, and the damage in her own words.

The confirmation shown after submitting, with the new claim reference — Claim registered - and behind that one message the workflow has already finished its work.

Step 10 - What Arrived on the Record

The claim's documents and communications panel: a generated external document and the email that carried it, both timestamped at submission — On the claim, filed the moment the form arrived: the generated document, marked external so the customer may see it, and the email that carried it.

This is the screenshot that shows the cost of skipping the document type in Step 1. The file is correct, external and attached to the right claim, and it is called other.pdf. Set the type on the template and it files under its own name.

The generated confirmation letter, the same template filled in with the claimant's name, the claim reference, the policy, the dates, the cause of loss and her description — The same template, filled in: her name, the reference, the policy, the dates, the cause of loss, and the damage in her own words. Nobody typed a line of it.

Check the three things that go wrong quietly. The recipient is the insured rather than a test address. The subject and body carry real values rather than an unsubstituted {##…##}. And the attachment is the document you meant.

The sent email record showing the recipient, the claim it is about, the rendered message and the confirmation letter attached as a PDF — And the email that carried it - addressed to the claimant, the claim's real reference filled in, and the confirmation attached as a PDF.

All three are visible on that one screen, and all three are the difference between an automation you trust and one somebody double-checks by hand every morning, which is not an automation at all.

What makes this worth doing is not that a letter gets sent. It is the shape: wording in a template, data on the record, and a workflow that points at both rather than containing either. Change the letter next quarter and every claim from that moment gets the new one, with no workflow to edit. Add a second step, a task for the handler, an SMS, a note to the broker, and it runs on the same trigger.

Start with the acknowledgment precisely because it is low-risk, and because once the customer gets an answer in five seconds instead of two days, the argument for automating the next step tends to make itself.