ServiceNow Integration Hub for Insurance

This page helps an integration lead decide how to connect claims, policy, rating and payment systems to ServiceNow. It compares a prebuilt spoke, a custom action and a direct REST call, and sets out how to keep each connection auditable, retry safely and owned after go-live.

How Insurance Organisations Use Integration Hub

Insurance organisations operate across claim processing, policy management, underwriting, and customer service systems. Each system—claims platforms, rating engines, customer databases, payment processors—holds critical data and business logic. Integration Hub allows insurance teams to connect these systems without custom code, orchestrate workflows that span multiple systems, and automate compliance-heavy processes that would otherwise require manual intervention.

Claims workflows are a typical use case. When a claim is submitted in ServiceNow, Integration Hub can immediately pull underwriting details from the policy system, check claim history via an internal API, calculate eligibility via a rating engine, and notify the claims team. Without integration, each step would require manual lookup and re-entry, introducing delay and error.

Processes and Stakeholders Specific to Insurance

Insurance workflows involve strict gatekeeping. A claim cannot be processed until underwriting has confirmed policy coverage; a policy cannot be renewed until compliance checks pass; a settlement cannot be paid until legal review is complete. Integration Hub helps enforce these gates by connecting systems so that one system can query whether another system’s conditions are met before proceeding. This is especially important in regulated insurance environments where proof of compliance is auditable.

Stakeholders include claims managers, policy administrators, underwriters, compliance officers, and IT operations. Claims teams want faster claim processing; underwriters want to enforce policy rules automatically; compliance teams want to see that all required checks are happening; IT operations wants to reduce manual handoffs and avoid re-keying data.

Data privacy is critical. Insurance holds sensitive information about customers, claims, and risk. Integration Hub connections must authenticate securely, validate data exchange, and log transactions for audit. Depending on your release and licensing, encryption and audit capabilities vary.

Design Decisions That Differ from Generic Implementations

Most generic Integration Hub implementations assume one-way data flow: read from source systems, update ServiceNow. Insurance often requires bidirectional flow and real-time synchronisation. When a claim is updated in ServiceNow, the rating system or claims system may need immediate notification. Design for near-real-time push rather than scheduled pull; use webhooks or event-driven integrations if possible rather than batch jobs.

Error handling is more critical in insurance. A failed integration might mean a claim is not processed, a policy is not renewed, or compliance documentation is missing. Design for graceful degradation: if an integration call fails, what happens? Is the request queued for retry? Is a human notified? Is the transaction rolled back? Define these scenarios explicitly rather than leaving them to chance.

Audit and compliance logging must be built into every integration. Insurance regulators expect to see who accessed what data, when, and why. Configure Integration Hub to log every API call, successful and failed, with request and response details. Store logs for the retention period your organisation is subject to.

Integration Patterns and Pitfalls

A common pattern is event-driven integration. When a policy is issued, an event fires in ServiceNow. Integration Hub captures that event and notifies all downstream systems: email service, document management, rating engine, premium collection system. This pattern ensures all systems are informed at the same time, reducing manual sync work.

Avoid tightly coupling systems. If claim processing depends on the policy system, what happens when the policy system is down for maintenance? Design integrations with fallback logic: queue the request, use cached data, or alert a human to handle it manually. Tight coupling between critical systems creates fragility.

Testing is often underestimated. Integration bugs affect multiple systems. Before deploying an integration to production, test with realistic claim scenarios: claims that should succeed, claims that should fail, partial data, network timeouts, and error responses from external systems. Many insurance organisations require integration testing as part of change management.

Implementation Checklist

Identify all systems that must integrate: name them, document their APIs, determine data ownership. Map data between systems; define transformations if field names or formats differ. Design error handling and logging. Identify who approves changes to integrations: is it the IT platform team, the business owner, or compliance? Configure authentication and encryption. Test with real data if possible, anonymised if required. Train operations teams on monitoring and troubleshooting. Set up alerts for failed integrations and ensure someone responds promptly.

Choosing between a prebuilt spoke, a custom action and a direct REST call

The reader for this section is the integration lead who has to connect a claims, rating or payment system to ServiceNow and decide how to build the connection. Integration Hub gives three broad ways to do it, and the right one depends on the type of system at the far end. The wrong choice does not usually fail on day one. It fails later, when the vendor changes an endpoint and nobody can say who owns the connection or how it was tested.

The Integration Hub flow design guidance covers designing a flow as controlled orchestration across ServiceNow, other systems and responsible teams. The choice here is about ownership. Whichever option is picked, a named person must be able to answer what the connection does, what it sends, and how it behaves when the far end stops responding.

Onboarding a carrier or vendor API, step by step

1. Confirm the exact API version in use, the retirement date for that version, and the team on the vendor side who announces changes.
2. Obtain a test environment from the vendor, and confirm that it behaves like production for the fields you need.
3. Design the credential as a dedicated service account with the narrowest permission that works, and agree how and when it is rotated.
4. Map each field, recording any transformation and the reason for it, so that a reviewer can trace a value from source to record.
5. Define a transaction identifier for every request, and check it on the receiving side before any state changes.
6. Set timeouts and retry limits explicitly, and decide which failures retry automatically and which go to a person.
7. Test with injected failures: a timeout, a rate-limit response, a malformed reply and a partial success.
8. Go live with monitoring in place for failed calls, and a named owner who responds to them.
9. Write the decommission path now, including how queued messages are drained or reconciled if the connection is retired.

Idempotency and duplicate transactions

Consider a flow that submits a premium adjustment to a rating service and receives no answer before the timeout. The flow retries. If the first request was processed, the retry creates a second adjustment. The fix is an identifier that travels with every request, so that the receiving system can recognize a repeat and return the original result. Where the vendor cannot support that, the flow must check the state of the record before retrying, and must not assume that a silent failure means nothing happened. Design this with the vendor before go-live, because a retrofit is harder once transactions are flowing.

Reconciling after an outage

When a connection has been down, the temptation is to replay everything that was queued. Replay is safe only if the receiving side handles repeats correctly. Otherwise, reconcile by record. Compare the count and the identifiers of transactions sent with those confirmed by the other system for the outage window, and replay only the gap. Document the reconciliation as a step in the outage procedure, because the person who runs it on the night is rarely the person who designed the connection.

Keeping vendor rate limits from becoming outages

A batch job that works in testing can exhaust a vendor’s rate limit in production, particularly after a backlog builds up. Read the limit from the vendor’s documentation, set the flow’s concurrency below it, and spread backlog replays over a longer window rather than sending them at once. Watch for rate-limit responses in the monitoring, because they often appear before a visible failure. The integration error handling guidance covers error handling that a support team can act on, including deciding what happened and what to do next.

When Integration Hub is the wrong tool

Three situations need a different approach. Bulk loads of historical policy or claims data are better handled through import sets and transform maps, which give repeatable validation and a load history. Streams of high-frequency events from a monitoring or telemetry source need an event-oriented design, not a flow per event. Anything that must answer within a very short response time for a customer on a live call should be designed around that response requirement from the start, and not left to a flow that waits for several systems in turn.

Signs the integration estate needs attention

• Nobody can name the owner of a connection, or the owner has changed role without a handover.
• Connection credentials have not been rotated since they were first created.
• Vendor notices arrive in a mailbox that nobody reads.
• Failed calls are retried by several flows that each implement their own retry rule.
• Log entries contain full personal details because the logging was never reviewed.

Questions about integrations in an insurance platform

Who owns an integration after go-live?

A named technical owner and a named business owner, both recorded on the integration record. The technical owner answers for the connection. The business owner answers for what the data is used for and approves changes that alter it.

How should a vendor API version that is being retired be handled?

Plan the move to the new version as a change, with its own test cycle and its own rollback. The API contract versioning guidance covers version behavior, deprecation and dependencies in an API contract.

Do test credentials need the same controls as production?

They need controls proportionate to the data they can reach. A test account that can read real policyholder records is a production risk, so restrict its data, keep its rotation rules and remove it when the project ends.

Should every integration call be logged in full?

No. Log enough to trace a transaction and diagnose a failure, with personal details redacted or restricted to the people who need them. A complete log of every request and response can become a second copy of the policyholder data, with its own retention and access problems.