---
title: Insert claim
summary: Persists a newly created claim header, applies New-status defaults, and validates business rules before the first save of a claim.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Entry
reference_type: package
operation_id: OP-CE-02
trigger: Caller calls Save() on a claim object whose IsNew flag is true
---

# Insert claim

After a claim has been created and populated by the caller (see [Create new claim](create-new-claim.md)), calling `Save()` for the first time routes through the insert lifecycle. This operation applies status-driven defaulting, runs the object's validation rules, and issues the insert statement(s) that create the persistent claim row (and, for New-status claims, cascades a status-history row).

| Field | Value |
| --- | --- |
| **Operation ID** | OP-CE-02 |
| **Trigger** | `Save()` invoked on a claim object where `IsNew = True` |
| **Inputs** | Fully populated claim header fields, `ClaimStatusCode`, acting worker/user context |
| **Outputs** | A new `CL_INJURY_CLAIM` row; for New-status claims, a companion status-history row; `UpdateNum` initialized to `1` |
| **Primary components** | `clsClaimEntry.BeforeInsert`, `clsClaimEntry.AddNewStatusData`, `clsClaimEntryBusinessRules` |
| **Entry point** | `Business\SAIF.Business.Claim.Entry\clsClaimEntry.vb` |

## Steps

1. **Validate before insert.** `Save()` (inherited BOF lifecycle) checks `IsValid` before dispatching to `BeforeInsert`; because every rule body in `clsClaimEntryBusinessRules.vb` is commented out and `AddBusinessRules()` is empty, no field-level broken rules are actually raised at this stage.*
2. **Apply New-status defaulting.** If `ClaimStatusCode = "N"` (New), `AddNewStatusData` populates additional header fields expected for a New claim before the insert executes, including setting the active-claim flag to `'Y'` ([BR-CE-004](../business-rules.md#br-ce-004-active-claim-flag-is-y-only-when-status-is-new)).
3. **Bind and execute the insert statement.** `BeforeInsert` builds parameter bindings for the claim header fields and issues the insert against `CL_INJURY_CLAIM` ([SQL-010](../sql/SQL-010.md), [CL_INJURY_CLAIM](../database-tables.md#cl_injury_claim)).
4. **Initialize `UpdateNum` to 1** as part of the same lifecycle call, establishing the optimistic-concurrency baseline used by subsequent updates ([BR-CE-011](../business-rules.md#br-ce-011-optimistic-concurrency-update-fails-if-rowsaffected-1); see [Update claim](update-claim.md)).
5. **Cascade auxiliary status rows for New-status claims** ([BR-CE-013](../business-rules.md#br-ce-013-saving-a-new-status-claim-cascades-auxiliary-status-rows)). When `ClaimStatusCode = "N"`, the same save cycle also persists request-decision, status-activity, type-activity, MCO-eligibility, and policy-history rows via the New-status data bindings established in step 2 ([SQL-005](../sql/SQL-005.md), [SQL-006](../sql/SQL-006.md), [SQL-007](../sql/SQL-007.md), [SQL-008](../sql/SQL-008.md), [SQL-009](../sql/SQL-009.md)).
   - On failure: the insert is rolled back as a unit by the surrounding data-portal transaction; no partial claim/status-history state is expected to persist.*
6. **Detect other open claims for the same worker.** `CheckForMultipleClaimsForWorker` queries for the most recently updated other claim tied to the same worker within a 14-day injury-date window ([BR-CE-012](../business-rules.md#br-ce-012-multi-claim-detection-returns-the-most-recently-updated-same-worker-claim-within-a-14-day-injury-date-window), [SQL-016](../sql/SQL-016.md)); see [Check multiple claims for worker](check-multiple-claims.md) for the full detection logic.
7. **Return the saved object** with the newly assigned `ClaimID`/`UpdateNum` to the caller.

## Process flow

```mermaid
flowchart TD
	Start([Save called on new claim]) --> Valid{IsValid?}
	Valid -->|No| Errors([Return broken rules])
	Valid -->|Yes| StatusCheck{ClaimStatusCode = New?}
	StatusCheck -->|Yes| NewData[Apply New-status<br>defaults]
	StatusCheck -->|No| Insert[Insert CL_INJURY_CLAIM row]
	NewData --> Insert
	Insert --> UpdateNum[Initialize UpdateNum = 1]
	UpdateNum --> HistoryCheck{ClaimStatusCode = New?}
	HistoryCheck -->|Yes| History[Insert status-history row]
	HistoryCheck -->|No| Multi[Check multiple open<br>claims for worker]
	History --> Multi
	Multi --> Return([Return saved claim])
```

## Failure and edge-case behavior

- Because business-rule bodies are commented out in `clsClaimEntryBusinessRules.vb`, malformed or incomplete claim data is not blocked at the object level before the insert executes; any rejection would have to come from database constraints.*
- The multiple-open-claims check in step 6 surfaces the matching claim number to the caller; it does not itself block the insert ([BR-CE-012](../business-rules.md#br-ce-012-multi-claim-detection-returns-the-most-recently-updated-same-worker-claim-within-a-14-day-injury-date-window)).
- If the New-status history insert (step 5) fails after the header insert succeeds within the same transaction scope, the data-portal transaction is expected to roll back both; no compensating logic exists in `clsClaimEntry` itself.*

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts.

## Sources

- `Business\SAIF.Business.Claim.Entry\clsClaimEntry.vb`
- `Business\SAIF.Business.Claim.Entry\clsClaimEntryBusinessRules.vb`