How We’ve Built a Micro Low-Code Platform to Help Insurance Business Users Change Business Logic Fast and Easy. Part I

Great as the Solution sounds, business users still will have to write acceptance criteria and create tickets, plan sprints, and then test changes. No matter where changes occur — in the Rules engine, UI, or in the applications themselves — these are still changes to the core logic, which can't just be made without all this bureaucracy. 

In terms of the process within the client's company, nothing will change significantly. However, the business rules will be created much faster, reused multiple times, and the paycheck for the insurance automation software will be way smaller than before.

All due to the main advantages of using the Rules engine for insurance application development:

1. It's a centralized place to store/manage core business logic
2. Traceability of every decision made
3. Transparent visualization of the decision-making process
4. Workflow rules stored here can be reused by an infinite amount of applications

Before the Rules Engine, the business logic was hardcoded in the applications themselves. The same logic oftentimes was duplicated in multiple places and even did not match, while it should have. 

After the Rules Engine:

1. A stand alone business logic in a new separate centralized system will allow manipulating the business logic of the application without actually changing the code (read – requires no insurance software development skills).
2. In fact, the Rules Engine abstracts the business logic from the system in which it is executed. Thus, changes in the business logic do not require changes to the system in which it is executed.

But don’t just take my word for that. Give a look to the MS Rules Engine description.

As for the pros of implementing this approach in the client's company, this is what they have now:

• The functionality that allows to centralize and reuse their business logic

Roughly speaking, several applications can reuse the same workflow if they solve similar tasks. After all, it’s all about efficiency – dozens of client’s applications relate solely to quotes, policies, and eligibility and are very similar to this product.

• The ability to visualize business logic

Logical chains are clearly visible on the graph – it is clear now which result will be returned to the client under the given circumstances.

• Non-developers will be able to change the business logic

Who will change it then? Business analysts or specifically trained business users (more on that later).

We have the basic concept of Workflow.

Workflow is a collection of business rules that are somehow connected to each other.

Have a look at an example of Workflow that we have prepared for you below. The business logic of the application is presented as a wide diagram. The parent Workflow is on top and can contain many nested Workflows.

The user can configure the Workflow through the UI and then integrate with it in their own application. Each configured rule has an execution result: success or failure. By aggregating the results of all executed rules the user – the agent – receives the final result: quote approved or rejected.

Let's see together how the integration works between the Restaurant Insurance Product and Rules Engine.

Case 1: June, the agent, fills in the form using the Product Software. For the insurance payout the limit is set equalling 3M for this type of policy. Let's say, the agent enters 5M. At the same moment, Rules Engine checks this limit through a series of aggregated business rules, and the system simply won't let June proceed with the form.

Each rule has a success action and a failure action. If June enters a limit of 3M, she will get back a success action. If it is 5M, this is a failure action. This is a response for non-qualifying policy holders stating – We do not have a reason to approve the quote for now. If all the rules result in one big failure, June will have to deny insurance coverage or go to her underwriter and discuss the terms of this insurance in person.

Such quote approvals/rejects are done automatically at once for dozens of applications that reuse the logic that was added to the Rules Engine once.

Case 2: The Product goes into production, after which the underwriters and agents start providing feedback. For example, some field or functionality is missing. The team needs to add it urgently to their UI. How can Rules Engine save the day?

If a Product lacks some field in the response, the team simply opens their Workflow, finds the rule they need there and adds additional results.

That is, if an underwriter comes and says “Guys, we’re missing one important message”, the team opens the Rules Engine and adds or changes the rule themselves, without my involvement or without the involvement of anyone else.

There is a list of users eligible to edit the Rules – both from the development and business side. They open the application, click the Edit button, make the necessary changes and that’s it. They can also test the changes right in the application, by switching to the staging environment – click the Staging environment button, and see how it works.

At the moment, these are mainly developers that integrate with the Rules Engine. In the future, there will be a group within the client’s company in charge of such business changes. The group is already undergoing training. As soon as the platform proves safe to be used by the test group, the circle of business users will be extended.

Ideally, dozens of insurance software projects can store their central logic on such a platform, and hundreds of business users will be able to change it independently.

For ordinary users who are completely unfamiliar with programming algorithms and languages, some professional training is required. Ideally, this should be a deep course in LINQ. A business/systems analyst with knowledge of SQL data types and logical operations will be able to work with the system with no additional training. 

Also, since expressions do not use any custom language, but the well-known dynamic LINQ, users could use AI (for example, the ChatGPT) as a virtual assistant. In this case, the model will not even have to be trained separately (at least in the initial stages).

Btw, here’s a cool article from my colleague, Ilya, Head of R&D, on using ChatGPT in ERP development.

We’re creating a platform for others – dozens of insurance agent software teams – to come and create their own Workflows. It is the teams – the Restaurant Insurance Product team, the Title Insurance team, the Corporate Buildings Insurance team or Cyber Insurance team – who extend the platform, add new workflows and rules to it.

Say, Richie from the Product team needs A new workflow for discount calculation.

Suppose there is some loyalty factor in the insurance company. For example, this is how many years the policy holder has been insured with this company. Then a business user can create several rules.

Rule 1 (discount 10% if a policy holder resides in California and the factor is from 2 to 4 )

Expression: (input.LoyaltyFactor > 2 and input.LoyaltyFactor < =4 && input.State == CA)

Rule 2 (discount 20% if the factor is larger than 5)

Expression: (input.LoyaltyFactor >= 5)

1. Richie opens the graphical UI of the platform
2. Presses the “+” button
3. Adds a new workflow – A new workflow for discount calculation
4. Creates some new items – Rule 1, Rule 2
5. Integrates the changes in his app and
6. Uses the functionality that he created here via the UI.

Ah. Here’s another insurance platform our team has built for this client. It's an ETL-based Big Data Solution, so if you’re into ETL things, it’s a real nice read.

Under the hood is the Rules Engine from Microsoft, but I’ve already mentioned that.

The shell is React Flow, an open-source library. Firstly, OutSystems was used for the job, but in the end the choice was made in favor of React. React Flow library allows creating node-based editors and interactive diagrams which is perfect for visualizing complex nested, logically related entities/objects.

How do you like the project? Share your comments on our page on LinkedIn, or X. Or email us directly in the form below, if you would like to try out this technology for your business. Trust me on this one – this thing is reusable and will save you a ton of money on insurance software development.