Financial services use case · Salesforce + ServiceNow + OpenAI + Microsoft 365
Claim intake to decision
Claim notifications and attachments must be assembled and read before the assessor can compare the reported event with the applicable policy. Claims assessors receive an evidence-linked claim file with extracted facts, policy context and a recorded decision path.
Systems involved
What each system contributes
25 actions
- Chat Completions8
- Files4
- Uploads4
No pre-built connector is established for policy administration or claims systems; the workflow uses the insurer's authorized vendor interfaces and leaves policy and claim records in their existing systems. Core banking, lending, policy administration, claims, identity verification, KYC and sanctions screening have no pre-built Nexus connector. They are reached through the institution's approved APIs, database access or vendor interfaces, or as Rules + Code, inside the same workflow and with the same approvals and audit.
Architecture
One governed run
How it starts: A claim notification is received in Salesforce or through the designated Microsoft 365 intake channel.
Step by step
How the process runs
- 01
Establish the claim file
Link the Salesforce case, permitted Microsoft 365 correspondence and attachments to the restricted ServiceNow assessment work item.
- 02
Retrieve policy context
Call the authorized policy-administration and claims interfaces to obtain the applicable policy version, coverage references and existing claim identifiers.
- 03
Read the notification
The selected model extracts the reported event, dates, parties and supporting facts, citing document passages and marking details that still need confirmation.
- 04
Prepare the assessment
Rules compare established facts with explicit policy conditions and required-document checks, presenting the source wording and outstanding questions to the assessor.
- 05
Record and apply the decision
Following the named assessor's approval, a separate claims-system interface records the authorized outcome and returns its reference to the connected case records.
Control
Human decision and exception path
Human decision
The named claims assessor decides coverage, acceptance, denial or further investigation within the insurer's authority rules. Settlement amounts and payments require their designated approvals before any separate execution step proceeds.
Exception path
- Missing documents or unreadable facts trigger a documented information request rather than assumed claim values.
- Conflicting policy versions or uncertain coverage interpretation return to the responsible assessor.
- Existing claim identifiers and destination status are checked before creating or applying another claim-system action.
Evidence
What gets audited
- Notification, correspondence and attachment references.
- Policy version, extracted facts and condition-check results.
- Assessor decision, rationale and required settlement approvals.
- Claims-interface response and linked case updates.
Nexus runs on premises, in private or sovereign cloud, or air-gapped. Credentials stay in the vault, roles decide who can approve, and the execution record stays inside your deployment boundary.
Sovereignty and deploymentRelated
Patterns, connectors and next steps
- Salesforce-ServiceNow integration
Integration pattern · Customer cases and operational incidents share the right context without exposing internal work notes.
- Salesforce connector
73 pre-built actions
- ServiceNow connector
55 pre-built actions
- OpenAI connector
25 pre-built actions
- Microsoft 365 connector
45 pre-built actions
- Enterprise automation
Governed processes across the systems you already run.
- Lead to account and ERP handoff
Another financial services use case.
FAQ
Questions about this use case
- Does Nexus replace any of these systems?
- No. Each system keeps its own records. Nexus runs the process between them and records each decision.
- How does the run start?
- A claim notification is received in Salesforce or through the designated Microsoft 365 intake channel.
- What if a step is not covered by a pre-built action?
- No pre-built connector is established for policy administration or claims systems; the workflow uses the insurer's authorized vendor interfaces and leaves policy and claim records in their existing systems. Core banking, lending, policy administration, claims, identity verification, KYC and sanctions screening have no pre-built Nexus connector. They are reached through the institution's approved APIs, database access or vendor interfaces, or as Rules + Code, inside the same workflow and with the same approvals and audit.
- Does the model decide whether the policy covers the claim?
- No; it extracts and organizes the submitted facts, while the named assessor decides the outcome using the applicable policy and review process.
Use case review
Discuss this use case
Bring your version of the process. We will map the systems, approvals and evidence it needs.