Skip to content

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").
  2. Criteria.extraSQL always returns the fixed stored-procedure name "PK82284_CLAIM_TASK.SELECT_ADDITIONAL_FIELDS" used in step 3.
  3. 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 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). 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). - 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) — fails when ClaimID = 0. - FutureDateWarning (BR-002) — 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) — skipped when PriorityCode = MailID (an informational task); fails when Text is blank. - ValidTextLength (BR-005) — fails when Text exceeds 4000 characters. - ValidMailId (BR-003) — 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) so the claim-assignment check in step 7 also runs. - RTWAssignedClaim (BR-006) — 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.
  1. 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, Update task, and Soft-delete task 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.

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 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.

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