Skip to content

File and maintain appeals

This workflow loads the active appeal for a case, manages extension and oral-argument grids, and persists appeal changes while keeping claim context and security stable.

Field Value
Operation ID OP-APP-004
Trigger User saves frmAppeal
Libraries involved SAIF.Application.Claim.Legal, SAIF.Business.Claim.Legal, SAIF.Application.Claim
Screens frmAppeal
Inputs Appeal, extension, and oral-argument grid edits
Outputs Persisted clsAppeal, clsAppealExtension, and linked schedule records; refreshed appeal list

Steps

  1. clsAppealManager runs frmAppeal, loads the active appeal, and manages extension and oral-argument grids — owned by SAIF.Application.Claim.Legal.
  2. SAIF.Business.Claim.Legal persists clsAppeal, clsAppealExtension, and the schedule records linked to oral arguments (APPEAL, APPEAL_EXTENSION).
  3. SAIF.Application.Claim.Legal runs pre-save and post-save processing, reloads the current case, and returns the screen to the refreshed appeal list.
  4. Access to the screen remains subject to the default-restricted-access rule (BR-APP-002).
  5. ClaimAppManager keeps claim context and claim-security state stable while the appeal workflow changes the legal-case view — owned by SAIF.Application.Claim.

Process flow

The following diagram visualizes this workflow across components.

flowchart TD
    Start([User saves frmAppeal]) --> S1[clsAppealManager loads active appeal and grids]
    S1 --> S2[SAIF.Business.Claim.Legal persists appeal, extension, schedule records]
    S2 --> S3[Pre-save/post-save processing runs]
    S3 --> S4[Case reloaded; claim context held stable]
    S4 --> EndOk([Refreshed appeal list displayed])

Failure and edge-case behavior

  • View-only or no-access users: save actions are blocked by the default-restricted-access rule until an explicit update role is granted (BR-APP-002).

Sources

  • SAIF.Application.Claim.Legal/LegalNet/clsAppealManager.vb
  • SAIF.Application.Claim/ClaimAppManager.vb