A screen per request type
Each new service request needs its own form, its own validation and its own screen — so the backlog grows faster than the team can clear it.
SolServ StudioLow-Code Insurance Servicing & Workflow Platform
Configure the service request. The platform builds the rest.
Service request types, the fields they capture, the documents they need, the rules they run and the queues they travel through are all configuration. SolServ Studio turns that configuration into a working servicing journey.
Overview
A servicing studio, used as a foundation.
SolServ Studio runs policy servicing and operational case work — endorsements, requirements, corrections, complaints and the long tail of service requests that each need their own form, their own documents and their own approval path.
It is also the orchestration layer beneath the rest of the portfolio. Where a decision is needed it calls SuTra, rather than embedding the logic.
- Category
Low-Code Insurance Servicing & Workflow Platform - Role
Horizontal servicing and orchestration layer across the SolTech ecosystem - Configured by
Business administrators, without a code release - Used by
Policy servicing, operations, finance and back-office teams - Deployment
Cloud-ready or on-premise
The problem
Every new service request becomes a project.
Work tracked outside the system
Spreadsheets, mailboxes and informal handoffs fill the gaps between applications, and none of it is visible to a supervisor.
Integrations written by hand
Every core-system call is coded, tested and released individually, even when it is the same shape as the last one.
A servicing journey
Policy number in. Assigned case out.
None of the steps below are compiled into the runtime. Every one of them is configuration a business administrator can change.
Fetch policy
A configured connector action calls the policy and client APIs.
Map and populate
Response fields map into case fields by path, with no code in between.
Choose the request
The service request type determines everything that follows.
Render the form
Dynamic fields and the documents that request needs appear.
Run the rules
Eligibility, validation and routing evaluated declaratively.
Submit
Case, workflow, audit and outbound events committed together.
Assign
The case lands in the right queue with its SLA clock running.
Capabilities
What SolServ Studio does
Configuration studio
- Service request types defined as configuration
- Dynamic form fields, sections and layout
- Document requirements per request type
- Publish-time validation before anything goes live
- Published definitions are immutable and versioned
Runtime
- Forms rendered from the published definition
- Server-side validation, never trusted to the browser
- Dynamic values persisted with searchable projections
- Case snapshot captured as at creation
Workflow
- State machine with configured transitions
- Work queues and role-based assignment
- Maker-checker processes and approval hierarchies
- SLA tracking with automatic escalation
- Exception processing and case lifecycle history
Rules
- Declarative rule evaluation — administrators never write code
- Eligibility, validation and routing decisions
- Delegated to SuTra for enterprise-wide rule governance
Integration framework
- Connector registry for core and partner systems
- Request and response field mapping by path
- Chained actions, so one button can call several APIs
- Key-based field selection, not fragile positional binding
- Reliable outbound dispatch with retry and backlog visibility
Documents
- Document requirements raised from the request type
- Pluggable document store, including InstaDocs
- Staging for large or bulk uploads
Integration
A new API is configuration rows.
Connecting a core system means describing it, not coding against it. Nothing about a given API is compiled into the runtime.
- Connector
The system being called — endpoint, credentials, timeout and retry policy. - Connector action
What to invoke and what triggers it, such as a button on the case screen. - Field mapping
Where each value sits in the request and the response, expressed as a path.
Built from what breaks in practice
- Actions chain, because one screen action often needs two or three API calls
- Fields are selected by key rather than by position, so a reordered response cannot silently read null
- The mapping grammar is deliberately restricted, so a misconfiguration cannot become a security surface
- Raw request and response payloads are logged and searchable by case
Architecture principles
Configurable where it matters. Fixed where it should be.
Administrators get real power over the journey, and none at all over the runtime.
Configuration compiles
Configuration is validated and compiled into one immutable published definition, so a half-finished change cannot reach production.
No admin-authored code
Rules and mappings are declarative. There is no path by which a configuration change becomes arbitrary code execution.
Committed together
Case, workflow state, audit entry and outbound events are committed in one transaction, so an integration failure cannot lose a case.
Server-side authority
Validation, entitlement and module access are decided on the server. The browser is never trusted to enforce them.
What changes operationally
New request types in days
A new service request is configured and published, not built and released.
Work becomes visible
Every case sits in a queue with an owner, a state and an age.
Controls that hold
Approval hierarchies and segregation of duties are applied by the system every time.
A complete case history
Who did what, when, and what the system decided in between.
How long does a new service request take you?
Describe one servicing process — the form, the documents, the checks, the approvals — and we will show you what it looks like configured in SolServ Studio.