Skip to content

Manage notes and tasks

Recovery notes (clsThirdpartyNote) are free-text case annotations; recovery tasks (clsThirdpartyTask) are assigned, due-dated follow-up items. Tasks carry the more elaborate rule set, including a multi-outcome check (LastTaskDelete) that blocks or warns before the last remaining task on a case can be removed, echoing the pending-case delete restriction already documented for tasks in general (BR-004).

Field Value
Operation ID OP-TP-06
Trigger clsThirdpartyNote.NewThirdPartyNote / retrieval, and clsThirdpartyTask.NewThirdpartyTask / retrieval, each followed by property edits and Save()
Inputs CaseSeqNum, note category code, note text; task code (category), task text, assigned-to user name, task due date, marked-for-delete flag
Outputs Persisted THRDPARTY_CASE-scoped note rows and THRDPARTY_TASK rows; blocked or warned task deletions
Primary components clsThirdpartyNote.AddBusinessRules, clsThirdpartyTask.AddBusinessRules, clsThirdpartyTask.LastTaskDelete, clsThirdpartyTask.GetTaskDeleteCode
Entry point Business\SAIF.Business.Claim.ThirdParty\clsThirdpartyTask.vb

Steps

  1. Create or retrieve a note. Retrieval reads notes by case (SQL-059, THRDPARTY_CASE).
  2. Validate the note (IsValid):
  3. Note category code is required.
  4. Note text is required.
  5. Note text must not exceed 4000 characters.
  6. All three checks are collectively enforced by the note's business rules (BR-028).
  7. Persist the note via insert (SQL-028) or update (SQL-082) against THRDPARTY_CASE.
  8. On a rows-affected value other than 1: an insert/update error message is added.
  9. Create or retrieve a task. Retrieval reads tasks by case and, optionally, task code (SQL-045/SQL-046, THRDPARTY_TASK).
  10. Validate the task (IsValid):
  11. Case sequence number must be non-zero, i.e. the owning case must exist (BR-029).
  12. Task code (category) is required (BR-029).
  13. Assigned-to user name is required (BR-029).
  14. Task text is required (BR-029).
  15. While the task is dirty and not marked for delete, the due date must fall between today and one year from today — already documented at the library level as BR-003.
  16. While the task is dirty and not deleted, a due date that does not fall on a working day triggers a warning that the date will be shifted to the next work day (BR-030).
  17. Evaluate the last-task-delete guard (LastTaskDelete), only when the task is marked for delete. GetTaskDeleteCode() classifies the delete request against the case's remaining tasks and case status, and the rule branches on the returned code:
  18. Code 1: block the delete — pending-case tasks must be removed by deleting the case itself from the Review screen, matching the library-level rule already documented as BR-004.
  19. Code 2: block the delete — deferred and open claims must retain at least one future task.
  20. Code 3: the first attempt raises a confirmation warning ("last task is being deleted... click save to confirm"); a second attempt, tracked via m_LastTaskWarningGiven, allows the delete to proceed.
  21. Code 4: allow the delete outright.
  22. Any other code: block the delete with a generic "Task not found" error.
  23. Persist the task via insert (SQL-031), update (SQL-085), or delete (SQL-097) against THRDPARTY_TASK.
  24. On a rows-affected value other than 1: an insert/update/delete error message is added.

Process flow

The following diagram visualizes task validation, focusing on the multi-outcome last-task-delete guard.

flowchart TD
    Start([Caller creates, edits, or<br>marks a task for delete]) --> Basic[Validate case, code,<br>assignee, text]
    Basic --> BasicOk{Valid?}
    BasicOk -->|No| Fail([Broken rules returned])
    BasicOk -->|Yes| DueDate{Dirty and<br>not marked for delete?}
    DueDate -->|Yes| Range[Validate due date within<br>one year window]
    DueDate -->|No| MarkDel{Marked for delete?}
    Range --> WorkDay[Warn if due date<br>is not a working day]
    WorkDay --> MarkDel
    MarkDel -->|No| Save[Insert or update THRDPARTY_TASK]
    MarkDel -->|Yes| Code{GetTaskDeleteCode}
    Code -->|1: pending case| BlockPending([Error: delete via<br>case Review screen])
    Code -->|2: deferred/open, no future task| BlockFuture([Error: must retain<br>a future task])
    Code -->|3: last task, first attempt| WarnConfirm([Warning: confirm delete])
    Code -->|3: last task, confirmed| Save
    Code -->|4: allowed| Save
    Code -->|else| BlockUnknown([Error: task not found])
    Save --> Rows{RowsAffected = 1?}
    Rows -->|No| Contention([Insert/Update/Delete error added])
    Rows -->|Yes| Done([Changes persisted])

Failure and edge-case behavior

  • The working-day warning (code path in step 5) does not itself move the due date in the rule function; the warning message states the date "has been changed," implying the shift happens elsewhere in the UI or caller flow rather than inside this rule.*
  • The LastTaskDelete confirmation flow (code 3) relies on in-memory state (m_LastTaskWarningGiven) to distinguish a first attempt from a confirmed retry, so it only works within a single object instance's lifetime — a fresh retrieval resets the confirmation state.*
  • A rows-affected value other than 1 on any insert, update, or delete is treated as a DB contention failure rather than an exception (BR-005).
  • Note validation has no length-based warning tier below the 4000-character hard limit — text at or under the limit is accepted regardless of length.

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.ThirdParty\clsThirdpartyNote.vb
  • Business\SAIF.Business.Claim.ThirdParty\clsThirdpartyNoteCollection.vb
  • Business\SAIF.Business.Claim.ThirdParty\clsThirdpartyTask.vb
  • Business\SAIF.Business.Claim.ThirdParty\clsThirdPartyTaskCollection.vb