---
title: Claim task lifecycle — create, enrich, validate, save
summary: Creates a claim task bound to a claim, hydrates supplemental claim metadata through an Oracle package, validates it against six claim-task rules, and persists it through the inherited BOF save pipeline.
status: draft
owner: SAIF
last_reviewed: 2026-07-30
library: SAIF.Business.Tasks.Claim
reference_type: package
operation_id: OP-TC-02
trigger: Caller creates a clsClaimTask via clsClaimTask.NewTask and calls Save (directly or via clsClaimTaskGenerator)
---

# Claim task lifecycle — create, enrich, validate, save

`clsClaimTask` is a single business object whose create, field-enrichment, validation, and save steps are all governed by the same class and rule set, so this page documents them as one lifecycle rather than as separate operations. A new claim task is either bound to a claim through the constructor factory or filled from a retrieved row; either path resolves supplemental claim data (worker name, policy name, work status, and confidentiality flags) so the task can be displayed and validated, then a caller-driven edit/save cycle enforces six claim-task rules before persisting through the inherited BOF save pipeline.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-TC-02 |
| **Trigger** | Caller calls `clsClaimTask.NewTask(dpi, claimId[, createUser])` to start a new task, or the retrieval pipeline calls `Load`/`PostFill` on an existing row; the caller then edits properties and calls `Save()` or `SaveChild()` |
| **Inputs** | `ClaimID` (or `ClaimNum`), `MailID`, `Text`, `TaskDate`, `PriorityTask`, `CategoryCode`, `CreateUser` |
| **Outputs** | Saved `clsClaimTask` row; populated `ClaimNum`, `SAIFClaimNum`, `WorkerName`, `PolicyName`, `WorkStatus`, and confidentiality flags (`IsWorkerConflict`, `IsExposure`, `isHostileWrkr`, `isHealthIssue`); broken-rule collection on validation failure |
| **Primary components** | `clsClaimTask.NewTask`, `clsClaimTask.Create`, `clsClaimTask.PostFill`, `clsClaimTask.GetExtraFields`, `clsClaimTask.AddBusinessRules`, `clsClaimTask.Save`, `clsClaimTask.SaveChild`, `clsClaimTask.CopyTo`, `clsClaimTask.MarkCompleted` |
| **Entry point** | `Business\SAIF.Business.Tasks.Claim\clsClaimTask.vb` |

## Steps

1. **Create a new task.** `NewTask(dpi, claimId[, createUser])` builds a `Criteria` with the claim ID and create user, calls `dpi.DataAccessLayer.CreateObject(crit)`, and sets `CategoryCode` to `DEFAULTCATEGORY` ("CLMM").
   - `Criteria.extraSQL` always returns the fixed stored-procedure name `"PK82284_CLAIM_TASK.SELECT_ADDITIONAL_FIELDS"` used in step 3.
2. **BOF `Create()` override.** `Create()` calls the base creation path, sets `ClaimID` from the criteria, and calls `GetClaimData()`, which loads a `clsClaimData` for the claim if one is not already cached.

   > **Origin**: `clsClaimData.GetData` is implemented in `SAIF.Business.View.Claim`. That library is documented in the previous format, so no per-operation page exists; see [Operations and processes](../../saif-business-view-claim/operations-processes.md) in the `SAIF.Business.View.Claim` documentation set.
3. **`PostFill()` branches on whether the task is bound to a claim.**
   - If `MyCriteria.ClaimID > 0` (the normal create/retrieve path): call `GetClaimData()` and set `TaskContext.Key.Value` to the resolved `ClaimNum`.
   - Otherwise (a task instantiated without a claim context): call `GetExtraFields()` and reset `mailidNeedsValidation` to `False`, then `MarkClean()`.
4. **`GetExtraFields()` executes the package call ([SQL-001](../sql/sql-001-pk82284_claim_task-select_additional_fields.md)).** It builds a stored-procedure request against `MyCriteria.extraSQL`, passing `ClaimId` as input and `ClaimNum`, `SAIFClaimNum`, `WorkerName`, `PolicyName`, `WorkStatus`, `conflictFlag`, `exposureCode`, `healthIssue`, and `hostileWrkr` as input/output parameters ([BR-010](../business-rules.md#br-010-additional-claim-fields-come-from-the-oracle-package-contract)).
   - On return, it copies the output parameters back into the matching member variables and derives `m_isWorkerConflict` (`conflictFlag = "Y"`), `m_isExposure` (`exposureCode <> "0"`), `m_isHealthIssue` (`healthIssue = "Y"`), and `m_isHostileWrkr` (`hostileWrkr <> " "`).
5. **Caller edits the task.** Setting `ClaimNum` re-resolves `clsClaimData`, sets `ClaimID`, updates `TaskContext.Key.Value`, and runs the `ClaimNum` rule check. Setting `MailID` marks the task dirty, flags `MailIdNeedsValidation = True`, and runs the `TaskUser` rule check. Setting `Text` cleans the string (`clsCharacterAnalyzer.GetCleanString`), marks dirty, and runs the `Text` rule check.
6. **Validation (`AddBusinessRules`).** Six rules are registered, in addition to the rules inherited from `clsTask`:
   - `ValidClaimNum` ([BR-001](../business-rules.md#br-001-claim-number-must-be-valid)) — fails when `ClaimID = 0`.
   - `FutureDateWarning` ([BR-002](../business-rules.md#br-002-task-dates-cannot-be-more-than-two-years-in-the-future)) — skipped when deleted or not dirty; fails when `TaskDate` is more than two years in the future (unless it is the sentinel `Date.MaxValue`).
   - `ValidText` ([BR-004](../business-rules.md#br-004-task-text-is-required)) — skipped when `PriorityCode = MailID` (an informational task); fails when `Text` is blank.
   - `ValidTextLength` ([BR-005](../business-rules.md#br-005-task-text-is-limited-to-4000-characters)) — fails when `Text` exceeds 4000 characters.
   - `ValidMailId` ([BR-003](../business-rules.md#br-003-mail-id-must-be-valid)) — skipped when validation is not needed, the task is not dirty or is deleted, the task is informational, the mail ID matches the current data-portal user, or the user ID starts with `"TEST"` and the mail ID matches the suffix after `"TEST"`.
     - If the user does not have `CTTaskUpdate` resource access: check `RTWExternalUpdate` external access instead.
       - If that also fails: add an error naming the mail ID and deny access.
       - If it passes: register the additional `RTWAssignedClaim` rule ([BR-006](../business-rules.md#br-006-external-rtw-assignments-must-belong-to-the-claim)) so the claim-assignment check in step 7 also runs.
   - `RTWAssignedClaim` ([BR-006](../business-rules.md#br-006-external-rtw-assignments-must-belong-to-the-claim)) — only registered conditionally in step 6's `ValidMailId` branch; skipped when validation is not needed; fails when `clsClaimSecurity.RTWAssignedToClaim` reports the mail ID's RTW resource is not assigned to the claim.

     > **Origin**: `clsClaimSecurity.RTWAssignedToClaim` is implemented in `SAIF.BOF.Business`; see [clsClaimSecurity](../../saif-business/api/SAIF.Business/clsclaimsecurity.md) in the `SAIF.BOF.Business` documentation set.
7. **Save.** `Save()` calls `ApplyEdit()` then the base `Save`; `SaveChild()` calls `ApplyEdit()` then the base `SaveChild`. Both delegate persistence to the inherited BOF task save pipeline.

   > **Origin**: Insert, update, and soft-delete persistence for the underlying `TASK` row are implemented by `clsTask` in `SAIF.Business.Tasks`. That library is documented in the previous format, so no per-operation page exists; see [Insert task](../../saif-business-tasks/operations/task-record-lifecycle.md), [Update task](../../saif-business-tasks/operations/task-record-lifecycle.md), and [Soft-delete task](../../saif-business-tasks/operations/task-record-lifecycle.md) in the `SAIF.Business.Tasks` documentation set.
8. **Copy a task to a new assignee.** `CopyTo(mailID)` creates a fresh task bound to the same claim via `NewTask`, copies the source task's fields with the inherited `CopyTask`, and sets the new task's `MailID` to the passed-in value.
9. **Mark completed.** `MarkCompleted()` sets `Completed = True` only if `RequiresNotePadEntry` is true (the notepad flag is `"Y"`), then always sets the delete flag and marks the task dirty so the completed/deleted task is persisted on the next save.

## Process flow

The following diagram visualizes the create, enrich, validate, and save lifecycle.

```mermaid
flowchart TD
	Start([NewTask claimId, createUser]) --> Create[Create: set ClaimID,<br>GetClaimData]
	Create --> Bound{ClaimID > 0<br>in PostFill?}
	Bound -->|Yes| Resolve[GetClaimData,<br>set TaskContext.Key]
	Bound -->|No| Extra[GetExtraFields:<br>package enrichment call]
	Resolve --> Edit[Caller sets ClaimNum,<br>MailID, Text, TaskDate...]
	Extra --> Edit
	Edit --> Validate{AddBusinessRules:<br>six claim-task rules}
	Validate -->|Fails| Errors([Broken rules returned])
	Validate -->|Passes| Save[Save / SaveChild:<br>ApplyEdit then base Save]
	Save --> Persist[Inherited clsTask<br>insert/update/delete]
	Persist --> Done([Task persisted])
```

## Failure and edge-case behavior

- A task with `ClaimID = 0` fails [BR-001](../business-rules.md#br-001-claim-number-must-be-valid) and cannot be saved.
- `FutureDateWarning`, `ValidText`, and `ValidMailId` all short-circuit to a pass under specific conditions (not dirty, deleted, sentinel max date, informational task) rather than always evaluating the underlying check, so an already-clean or informational task can carry an otherwise-invalid value without blocking the save.*
- `ValidMailId` can add the `RTWAssignedClaim` rule dynamically at validation time; if that rule is never registered (the user has ordinary `CTTaskUpdate` access), the RTW-assignment check never runs for that save.
- If neither `CTTaskUpdate` nor `RTWExternalUpdate` access is present, the save is blocked with an explicit "does not have access to RTWExternalUpdate" message.
- `GetExtraFields()` runs only when the task has no bound claim ID at fill time; a claim-bound task instead relies on `clsClaimData` for the same information, so the two enrichment paths are mutually exclusive per task instance.

## 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.Tasks.Claim\clsClaimTask.vb`