Search
Solartis Builder is the no-code toolkit where P&C lines of business and programs are configured, maintained, tested, and promoted to production in Solartis Insure. Solartis initially configures your products in Builder. After launch, your business analysts or technical team can maintain them in Builder as they change over time, or Solartis can continue to maintain them for you.
Solartis Insure is the P&C policy administration platform that runs the full policy lifecycle across 200+ microservices. Solartis Builder is the no-code toolkit where the products running on Solartis Insure are configured, maintained, tested, and promoted to production. What you configure in Builder drives how the Solartis Insure microservices rate, quote, bind, issue, and service each policy.
Solartis Builder is a no-code insurance product configuration tool, used to configure and maintain products on the Solartis Insure policy administration platform. Business analysts configure rating, rules, forms, and screens without writing code, including rating algorithms through the Algorithm Wizard. Technical users can also write algorithms in DRL or Python when they need more control.
Solartis Builder configures every part of a P&C line of business or program:
Testing at the microservice and program level, and promotion from DEV → TEST → UAT → LIVE, also happen in Builder.
Solartis Builder organizes products in four layers, and each layer inherits from the one above it:
You configure only what is different at each layer, and everything else is inherited.
In Solartis Builder, rate tables are maintained separately from rating algorithms, so rates can change without changing the calculation. Coverages, rate tables, and valid values are configured at the policy, coverage, and exposure level, versioned by effective date, and rate tables can be imported from and exported to Excel.
Solartis Builder offers three ways to configure and maintain rating algorithms. Business analysts use the no-code Algorithm Wizard, and technical users can write algorithms in DRL (Drools Rule Language) or Python. Algorithms are kept separate from rate tables, each change gets its own effective date, and every update is tested and promoted through DEV → TEST → UAT → LIVE.
Underwriting, eligibility, and referral rules are configured in Solartis Builder without code and can be set by carrier, state, coverage, or program. Eligibility rules decide what can be quoted, and referral rules send quotes and policies to underwriters for review when set conditions are met. Every rule is versioned and tested before it moves to production.
Yes. UI screens, screen questions, and their rules are configured in Solartis Builder and rendered through the Solartis metadata microservice, so screens are mobile-responsive without separate development. Customers that use their own portal can skip Builder screens and call the same Solartis Insure microservices through APIs.
Solartis Builder manages every form in a central Forms Library, including ISO, AAIS, proprietary, and carrier-specific forms, with sharing across products, grouping, rules-based selection, and version control. Each form is mandatory, conditional (added when its rules are met), or optional. Proprietary and manuscript forms are authored in Microsoft Word with the Solartis Editor Plug-in.
Carriers on Solartis configure their deviations in Solartis Builder, the no-code configuration toolkit for the Solartis Insure policy administration platform, as a separate layer on top of pure ISO content, which Solartis consumes through ISO ERC. Examples include carrier-specific coverages, rate deviations such as surcharges or proprietary rate tables, proprietary forms, and carrier-specific eligibility or underwriting rules. The original ISO content is preserved, so the product stays aligned with ISO while reflecting what makes it different.
Yes. Across all bureaus, you choose how each update is adopted in Solartis Builder: automatically as it arrives, by a set date, or not at all. Nothing reaches production until you decide it should.
AI turns AAIS, NCCI, and MA AIB (Mass Auto) rating content, state filings, and Excel rating content into Builder-ready configuration, and creates and runs the test cases that confirm each configuration. ISO content comes in through ISO ERC, not AI. Every AI-generated configuration is reviewed and approved before it reaches production.
Effective dating makes sure each policy uses the rates, rules, and forms in effect for its dates. Insurers on Solartis get this in Solartis Builder, the no-code configuration toolkit for the Solartis Insure policy administration platform, where all content is versioned by applicable and effective date, future versions can be scheduled ahead of time, and every prior version is retained for policy processing. Carriers choose whether transactions use the rate in effect at the time or grandfather prior rates.
Testing and promotion are built into Solartis Builder. Teams run microservice-level tests, such as rating calculations, document generation, and underwriting rules, and program-level tests that simulate end-to-end policy transactions. AI creates and runs the test cases that confirm each configuration. Approved changes then move through a governed DEV → TEST → UAT → LIVE path, so nothing reaches production untested.
Yes. Multiple teams can work on the same product at once in Solartis Builder, for example one on rating, another on underwriting rules, and a third on documents and forms. Each team tests its work at the microservice level, and the full product is validated before it is promoted to production.
Insurers on Solartis update rates in Solartis Builder, the no-code configuration toolkit for the Solartis Insure policy administration platform. A business analyst edits rate tables directly or imports them from Excel, then sets the effective date. The change is tested, for example by running rating calculations, and promoted through DEV → TEST → UAT → LIVE. Future-dated rate changes can be scheduled ahead of time.
Insurers on Solartis add states in Solartis Builder, the no-code configuration toolkit for the Solartis Insure policy administration platform. A new state inherits the rates, rules, and forms already in the base product, so a business analyst configures only what is different, such as state rates, eligibility rules, and forms. States no longer written can be expired, and every change is tested before it moves to production.
Insurers on Solartis can place a moratorium in Solartis Builder, the no-code configuration toolkit for the Solartis Insure policy administration platform, at the state, county, city, or ZIP code level during severe weather or other events, such as wildfires or named storms. A business analyst chooses which transactions to cease, including binding, issuance, endorsements, renewals, cancellations, and reinstatements, and lifts the moratorium when conditions return to normal.
A business analyst adds a coverage in Solartis Builder by defining the coverage and its valid values, then configuring its rating, eligibility and underwriting rules, forms, and screen questions. The new coverage is tested at the microservice and program level before it is promoted to production.
Insurers on Solartis launch new programs in Solartis Builder, the no-code configuration toolkit for the Solartis Insure policy administration platform. Each new program inherits from the Customer Base Product, so a business analyst configures only the program-specific content, such as rates, rules, forms, and eligibility. Everything else carries over from the base product, which is why new programs can launch quickly.
A business analyst manages forms in the Solartis Builder Forms Library. Proprietary and manuscript forms are authored in Microsoft Word with the Solartis Editor Plug-in, then set as mandatory, conditional, or optional, with rules that decide when each form is added to a policy. Every form change is versioned and tested before it reaches production.
ISO circular updates arrive electronically through ISO ERC. Each update can be adopted by the circular’s effective date, by the carrier’s own adoption date, or not at all. Carrier deviations stay in their own layer, prior versions are retained for in-force policies, and every update is tested before it moves to production.
Every change in Solartis Builder is versioned by applicable and effective date, so a business analyst can see what changed, when it takes effect, and which version applies to each policy. Prior versions are retained, and rate versioning is fully auditable.
Insurers on Solartis maintain their products in Solartis Builder, the no-code configuration toolkit for the Solartis Insure policy administration platform. Business analysts make changes without code, then test them and promote them through a governed DEV → TEST → UAT → LIVE path, with no external IT release or DevOps cycle.
Yes. For highly specialized or bespoke programs, products can be built from scratch in Solartis Builder instead of inheriting from the Solartis Base Platform, with their own states, coverages, rates, rules, documents, and forms. They go through the same configuration, testing, versioning, and promotion process as every other product, and preserve your intellectual property and program differentiation.
Yes. Your team learns Solartis Builder by shadowing Solartis during the initial configuration of your products. Solartis then provides online training tools, and our business analysts work alongside your team on changes until you are comfortable making them on your own.
