---
title: Work release management
summary: Creates, updates, or deletes the claim's work-release-status child record to match the caller-supplied work release code and date.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Entry
reference_type: package
operation_id: OP-CE-08
trigger: clsStateClaimEntry.IsValid, via UpdateWorkReleaseStatus, during Save() of a state-jurisdiction claim
---

# Work release management

A state-jurisdiction claim carries a work-release-status child object whose lifecycle must track the claim's own `WorkReleaseCode` and `WorkReleaseDate` header fields. This operation is the reconciliation logic in `clsStateClaimEntry` that decides, on every save, whether the child record needs to be created, updated, or removed to stay consistent with those header fields — the actual CRUD and validation for the child record itself is implemented by `clsClaimWorkReleaseStatus` in `SAIF.Business.Claim`.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-CE-08 |
| **Trigger** | `clsStateClaimEntry.IsValid` invokes `UpdateWorkReleaseStatus` as part of validating a state claim before save |
| **Inputs** | `WorkReleaseCode`, `WorkReleaseDate`, the claim's deletion state, the existing work-release-status child object (if any) |
| **Outputs** | A created, updated, or deleted `clsClaimWorkReleaseStatus` child object |
| **Primary components** | `clsStateClaimEntry.UpdateWorkReleaseStatus` |
| **Entry point** | `Business\SAIF.Business.Claim.Entry\clsStateClaimEntry.vb` |

## Steps

1. **Require presence when either field is set.** If `WorkReleaseCode` or `WorkReleaseDate` is populated on the claim but no work-release-status child object exists yet, a broken rule is raised requiring the child record to be created before the claim can be considered valid ([BR-CE-005](../business-rules.md#br-ce-005-work-release-status-must-exist-if-work-release-date-or-code-is-provided-state-only)).
2. **Reconcile the child record's lifecycle against the header fields** ([BR-CE-015](../business-rules.md#br-ce-015-work-release-status-child-record-lifecycle-follows-presence-of-codedate-and-claim-deletion)):
   - If the claim itself is being deleted: mark the work-release-status child object for deletion as well, so it does not outlive its parent claim.
   - If both `WorkReleaseCode` and `WorkReleaseDate` are now blank and a child object exists: mark the child object for deletion, since there is no longer any work-release data to track.
   - If a child object does not yet exist and either field is populated: create a new work-release-status child object and populate it from the claim's `WorkReleaseCode`/`WorkReleaseDate`.
   - If a child object already exists and either field has changed: update the child object's code/date to match the claim header.
3. **Delegate the actual create/update/delete of the child row.**
   > **Origin**: `clsClaimWorkReleaseStatus` is implemented in [`SAIF.Business.Claim`](../../saif-business-claim/overview.md), which has been migrated to the current documentation format. Its sequence-number reservation, date validation, and insert/update/delete lifecycle are documented as [Work status and work release tracking](../../saif-business-claim/operations/work-status-and-release-tracking.md); this operation only reconciles when to invoke that lifecycle, not how the row itself is persisted.
4. **Persist the reconciled child object** as part of the same `Save()` call that persists the claim header (see [State insert extensions](state-insert-extensions.md)).

## Process flow

```mermaid
flowchart TD
	Start([IsValid runs during<br>state claim save]) --> Presence{Code or date set<br>but no child object?}
	Presence -->|Yes| Broken([Raise broken rule:<br>child record required])
	Presence -->|No| DeleteCheck{Claim being deleted?}
	DeleteCheck -->|Yes| MarkDelete[Mark child object<br>for deletion]
	DeleteCheck -->|No| BlankCheck{Code and date<br>both now blank?}
	BlankCheck -->|Yes, child exists| MarkDelete2[Mark child object<br>for deletion]
	BlankCheck -->|No| ExistCheck{Child object exists?}
	ExistCheck -->|No| Create[Create new child object<br>from code/date]
	ExistCheck -->|Yes| Update[Update child object<br>code/date]
	MarkDelete --> Persist([Persist reconciled<br>child object])
	MarkDelete2 --> Persist
	Create --> Persist
	Update --> Persist
```

## Failure and edge-case behavior

- The requirement in step 1 is enforced only as a broken rule during validation, not as a database constraint — a caller that bypasses `IsValid` could still attempt a save with inconsistent header/child state.*
- Deleting the parent claim cascades a delete to the work-release-status child object, but the underlying persistence of that delete depends on `clsClaimWorkReleaseStatus`'s own optimistic-concurrency check (`Rows affected = 1`), documented in the [Work status and work release tracking](../../saif-business-claim/operations/work-status-and-release-tracking.md) operation.
- No orphan work-release-status rows are expected to be created directly against the database outside of this reconciliation path, since the child object's own sequence-number reservation only runs when this logic creates it.*

## 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\clsStateClaimEntry.vb`