Skip to content

Caseload reassignment

When an EAIP specialist leaves, goes on leave, or has their caseload rebalanced, their work has to move in bulk. This operation is that bulk move. It has two modes: reassigning a chosen set of service periods directly, and reassigning every claim under a chosen set of policies by staging a participant assignment for the downstream assignment process. Both bypass the ordinary business-object save path and write directly to the database, which makes this the one place in the library where EAIP period ownership changes without optimistic concurrency protection.

Field Value
Operation ID OP-EAIP-11
Trigger Supervisor populates clsReassignment with a specialist and either a list of EAIP period identifiers or a list of policy numbers, then calls UpdateClaimAssignment(dpi) or UpdatePolicyAssignment(dpi)
Inputs IDataPortalInfo (supplies the acting user); the target EAIP specialist's user name; a list of EAIP period identifiers (period mode) or a list of policy numbers (policy mode)
Outputs Period mode: updated EAIP_PERIOD owner, update stamp, and incremented update number, returning whether any row changed. Policy mode: one PARTICIPANT_STAGING row per distinct policy for the resolved specialist, returning false when the specialist cannot be resolved. Rule violations when no specialist or no rows were selected
Primary components clsReassignment (Rule_HasEaipSpecialist, Rule_HasIDs, UpdateClaimAssignment, UpdatePolicyAssignment)
Entry point Business\SAIF.Business.Claim.EAIP\Period\clsReassignment.vb

Steps

  1. Select the target specialist and the work to move. The supervisor sets the EAIP specialist's user name and populates either the EAIP period identifier list (to move individual service periods) or the policy number list (to move everything under a policy).
  2. Validate the selection. Rule_HasEaipSpecialist requires a specialist, and Rule_HasIDs requires at least one selected row with the message "Must select at least one row to update." Together they prevent an empty or untargeted bulk update.
  3. Period mode — build the update. UpdateClaimAssignment(dpi) issues an inline update against the EAIP period table setting the EAIP user to the bound specialist, the update date to sysdate, the update user to the acting user, and the update number to itself plus one, restricted to the selected period identifiers.
  4. Note how the identifier list is applied. The selected identifiers are de-duplicated and joined into a quoted, comma-separated literal that is interpolated into the in clause rather than bound as parameters. The values originate from a selection grid rather than free text, but the pattern is unsafe and also caps the update at whatever list length the database permits in an in clause.*
  5. Note the concurrency bypass. The update force-increments the update number instead of matching it against a previously read value, so it deliberately overwrites concurrent edits to the same service period rather than detecting them — the opposite of the protection applied on the ordinary period save path (BR-PROC-002). The rest of the period update path is described in Service period management.
  6. Report the outcome. UpdateClaimAssignment returns true when the statement reported a non-zero row count. It does not compare that count to the number of periods selected, so a partial match reports success.*
  7. Policy mode — resolve the specialist. UpdatePolicyAssignment(dpi) first reads the system user cross-reference identifier for the named specialist, matching on the trimmed user name. When no identifier comes back, the method returns false immediately and stages nothing — the specialist must already exist as a system user before any policy can be reassigned. Here too the specialist name is concatenated into the statement text rather than bound.*
  8. Stage one assignment per policy. For each distinct policy number the method inserts a participant staging row: the identifier from the participant staging sequence, the resolved system user cross-reference identifier, the policy number, a team function code of EAIP, a group name of EAIP, and a bulk-assignment flag of N. The staging table is the hand-off point; a downstream assignment process consumes these rows and applies the ownership change to the claims under each policy.*
  9. Return. Policy mode returns after the last insert. The claims themselves are not touched by this library in policy mode — only the staging rows are written, so the visible reassignment happens whenever the consuming process next runs.*

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Supervisor selects rows and<br>names a new specialist]) --> Val{Specialist set and<br>at least one row selected?}
    Val -->|No| Rej([Rule violation:<br>Must select at least one row to update])
    Val -->|Yes| Mode{Which mode?}
    Mode -->|Periods| Upd[Inline update of EAIP_PERIOD:<br>eaip_user, sysdate, update_user,<br>update_num + 1]
    Upd --> List[Period ids de-duplicated and<br>interpolated into the in clause]
    List --> Rows{Any rows updated?}
    Rows -->|No| False([Return false])
    Rows -->|Yes| True([Return true;<br>count not compared to selection])
    Mode -->|Policies| Res[Read SYSTEM_USER_XREF id<br>for the trimmed specialist name]
    Res --> Found{Identifier found?}
    Found -->|No| Stop([Return false; nothing staged])
    Found -->|Yes| Stage[Insert one PARTICIPANT_STAGING row<br>per distinct policy: EAIP team function,<br>EAIP group, bulk flag N]
    Stage --> Done([Staged for the downstream<br>assignment process])

Failure and edge-case behavior

  • The period update force-increments the update number without checking it, so a concurrent edit to the same service period is silently overwritten instead of raising a contention error.
  • Both the period identifier list and the specialist name are concatenated into statement text rather than bound as parameters. The values come from selection lists and a resolved user name, but the pattern offers no injection protection.
  • The period update reports success on any non-zero row count. If some of the selected periods no longer exist, the caller is told the reassignment succeeded.*
  • Policy mode writes only staging rows. Until the downstream process consumes them, the claims still show the previous specialist, and this library provides no way to observe or reverse a pending staging row.*
  • A specialist who exists in EAIP but not in the system user cross-reference silently fails policy reassignment with a false return and no message explaining why.
  • Neither mode writes history: nothing in this operation records who reassigned what, beyond the update user stamped onto the period row in period mode.*
  • Each staging insert is issued individually with no surrounding transaction in this code, so a failure part-way through leaves some policies staged and others not.*

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.EAIP\Period\clsReassignment.vb
  • Business\SAIF.Business.Claim.EAIP\Period\clsPeriod.vb