System of Record versus System of Action in Insurance

Most insurance delivery disputes are not really about tooling. They are about authority: which system is allowed to decide, to hold the truth and to be believed when two records disagree.

When that question is left implicit, the workflow layer slowly accumulates copies of policy data, fragments of pricing logic and unofficial financial positions. The result looks like progress for a release or two, then becomes a reconciliation problem that nobody owns. Settling authority early is cheaper than unwinding it later.

System of record versus system of action: the working position

A defensible split is simple to state. The workflow platform owns case state, assignment, service levels, approvals, correspondence, evidence and history. The specialist platforms own policy, claims, finance and reinsurance transactions, together with the product rules and calculations that produce them.

Everything else in this paper follows from that sentence: what data may be copied, how interfaces are designed, how failure is handled and who is accountable in production.

Which system owns what: a responsibility matrix

Write this down before the first sprint, review it with the accountable owners and treat any disagreement as a design defect rather than a delivery detail.

Reference architecture for workflow and core insurance systems

Four boundaries need to be explicit. Channels convert demand into one identifiable case. The workflow layer holds operational context. An integration layer mediates every exchange with authoritative systems. Those systems retain their transactions and calculations.

The important design rule is directional. The workflow layer may read from the core, reference it, or request an authorised transaction. It should not become the place where the core's answer is recomputed.

How to minimise data copied into the workflow platform

Distinguish three categories. Identifiers, such as policy, claim, party or treaty references, should be stored to correlate work. Working context, such as a short description, class of business, jurisdiction or handler note, may be stored because it belongs to the case. Authoritative data, such as premium, coverage, reserves, ledger balances and settlement status, should be referenced at the point of use rather than copied into a parallel store.

Where a value must be displayed inside the case, retrieve it on demand or show it with an explicit source and timestamp. Where a value must be retained for evidence, retain it as a dated snapshot attached to a decision, not as a field that will silently drift from the source.

Which integration pattern to use, and the controls it needs

How to design for integration failure

Assume timeouts, duplicates and uncertain write-backs. Every case that initiates a transaction needs a recoverable state: requested, confirmed, failed or unknown. Correlation identifiers should be carried through every hop so that a support engineer can reconstruct what happened without guessing. Where an outcome is uncertain, the safe behaviour is to hold the case for confirmation rather than assume success.

Security, privacy and audit evidence across the boundary

Use managed identities and least-privilege scopes for each interface rather than one shared credential. Classify the data crossing each boundary and record why it needs to cross. Separate administrative access from operational access. Correlate logs across the workflow platform, integration layer and core systems so an audit question can be answered from evidence rather than reconstruction. Set retention explicitly for case records, correspondence and attached evidence, and align it with the retention applied to the authoritative record.

Six questions to settle in the design review

Before development starts, settle the following. Each has a written answer or the design is not ready.

1. Which system is authoritative for every material field, rule and transaction in scope?
2. What is the minimum case model needed to move the work, and what has been deliberately excluded?
3. What is the interface contract for each exchange, including schema, error semantics and ownership?
4. What is the threat model for the data crossing each boundary, and which controls address it?
5. How does the service behave and recover when a core system or interface is unavailable?
6. Who owns the workflow, each integration and the reconciliation in production, by name and by rota?

Where ServiceNow sits as the system of action

ServiceNow is a strong candidate for the system of action. Its case management, role-based workspaces, approval and service-level capabilities map directly to the responsibilities above, and Integration Hub supports API-led integration, reusable spokes and remote tables that expose external data without permanently importing it.

That capability makes the discipline more important, not less. Because the platform can hold almost any data model, the temptation to absorb core insurance data is real. The architectural boundary has to be an explicit decision, documented and enforced in review, rather than a consequence of whatever was convenient in the last sprint.

Impactron's insurance practice works with architecture and delivery teams to set these boundaries, design the integration layer and deliver workflow on ServiceNow without eroding the authority of the systems that hold the insurer's records.