---
title: Set worker context
summary: Loads an application session from a worker identifier and runs the same security and retrieval pipeline used for claim-number entry.
status: draft
owner: Technical Writer
last_reviewed: 2026-07-30
library: SAIF.Application.Claim
reference_type: package
operation_id: OP-AC-02
trigger: Caller invokes SetWorkerContext(Decimal) with a worker ID
---

# Set worker context

This operation establishes an application session scoped to a worker rather than a specific claim. It reuses the same `ChangeContext()` pipeline as claim-number and claim-ID entry (security evaluation and subclass retrieval), but the worker-only `ClaimContext` constructor does not populate `ClaimNumber`, which changes how claim data resolves in practice.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-AC-02 |
| **Trigger** | Caller calls `SetWorkerContext(inWorkerID As Decimal)` |
| **Inputs** | Worker ID (`Decimal`) |
| **Outputs** | Active worker-scoped `ClaimContext`, claim-data lookup attempt, updated `ClaimSecurity` snapshot, subclass-specific retrieved state |
| **Primary components** | `ClaimAppManager.SetWorkerContext`, `ClaimAppManager.ChangeContext`, `ClaimContext`, `ClaimSecurity`, `clsClaimData` |
| **Entry point** | `Application\SAIF.Application.Claim\ClaimAppManager.vb` |

## Steps

1. `SetWorkerContext(inWorkerID As Decimal)` checks `inWorkerID > 0`.
   - If true: creates `New ClaimContext(0, inWorkerID)` (claim ID `0`, worker ID `inWorkerID`) and calls `ChangeContext()` (step 2).
   - If false (zero or negative): the method returns without creating a context, calling `ChangeContext()`, or setting a caller-facing message.* Unlike the two `SetClaimContext` overloads, there is no `Else` branch here.
2. `ChangeContext()` runs the same pipeline as [Set claim context](set-claim-context.md): `OnContextChanged()`, then `OnCheckSecurity()`, then `OnRetrieve()`.
3. `OnContextChanged()` calls `GetClaimData()`, which reads `Context.ClaimID` first.
   - Because the worker-only constructor sets `ClaimID = 0`, `Context.ClaimID > 0` is false, so `GetClaimData()` falls through to `clsClaimData.GetData(DPI, Context.ClaimNumber)` — and `Context.ClaimNumber` was never assigned for a worker-only context, so it retains its default empty-string value.**
     - Sub-step: `clsClaimData.GetData` is the same retrieval call embedded in [Set claim context](set-claim-context.md#steps).

       > **Origin**: Claim retrieval is implemented by `clsClaimData.GetData` in `SAIF.Business.View.Claim`. That library is documented in the previous format, so no per-operation page exists; see [Retrieve claim summary data](../../saif-business-view-claim/operations/claim-summary-and-detail-retrieval.md) in the `SAIF.Business.View.Claim` documentation set.
   - `Context.WorkerID` is never read by `GetClaimData()` in this library's source, so the worker ID supplied to `SetWorkerContext` does not directly drive claim resolution in the base `ClaimAppManager` implementation.**
   - As in claim-number entry: `Message` defaults to `ClaimAppConstants.CLAIMNOTFOUND` and the context is marked not-set; if `m_ClaimData.IsValid` becomes true, `Message` clears and `MarkContextSet()` runs instead.
4. `OnCheckSecurity()` runs identically to the claim-context flow: `ClaimSecurity.CheckClaim(ClaimData)` evaluates conflict ([BR-001](../business-rules.md#br-001-conflict-claims-require-conflict-access-or-an-override)), exposure ([BR-002](../business-rules.md#br-002-exposure-claims-require-exposure-access)), hostile-worker ([BR-003](../business-rules.md#br-003-hostile-worker-claims-require-secure-claim-access)), and health-issue access ([BR-004](../business-rules.md#br-004-health-issue-exposure-claims-reuse-exposure-authorization)); `MarkViewOnly()` runs by default, and a failed conflict check falls back to `CheckForSecurityOverride()`.
   - Sub-step: `CheckForSecurityOverride()` delegates to `ClaimServices.HasOverrideAcess`.

     > **Origin**: The security-override lookup is implemented by `ClaimServices.HasOverrideAcess` in `SAIF.Business`. That library is documented in the previous format, so no per-operation page exists; see [Claim authorization and visibility checks](../../saif-business/operations/claim-information-and-authorization-support.md) (step 4, [SQL-014](../../saif-business/sql/SQL-014-override-security-lookup.md)) in the `SAIF.Business` documentation set.
   - On a failed override: `MarkNoAccess()` runs and `Message = ConfidentialAccessDeniedMessage` ([BR-001](../business-rules.md#br-001-conflict-claims-require-conflict-access-or-an-override)).
5. `OnRetrieve()` (abstract) runs in the concrete subclass to load application-specific state for the resolved context; this library does not implement it directly.*

## Process flow

The following diagram visualizes worker-context entry, including the claim-number resolution gap described in step 3.

```mermaid
flowchart TD
	Start([Caller invokes SetWorkerContext]) --> Valid{WorkerID > 0?}
	Valid -->|No| NoOp([No context change;<br>no message set])
	Valid -->|Yes| NewCtx[Create ClaimContext<br>ClaimID = 0, WorkerID = input]
	NewCtx --> ChangeContext[ChangeContext]
	ChangeContext --> GetData[GetClaimData:<br>ClaimID = 0, falls back to<br>blank ClaimNumber lookup]
	GetData --> IsValid{ClaimData.IsValid?}
	IsValid -->|No| NotFound([Context not set;<br>CLAIMNOTFOUND message])
	IsValid -->|Yes| ContextSet[MarkContextSet]
	ContextSet --> CheckSecurity[CheckClaim: conflict,<br>exposure, hostile, health-issue]
	CheckSecurity --> ViewOnly[MarkViewOnly]
	ViewOnly --> Conflict{ConflictAccess false?}
	Conflict -->|No| Retrieve[OnRetrieve in subclass]
	Conflict -->|Yes| Override{Security override granted?}
	Override -->|Yes| Retrieve
	Override -->|No| NoAccess([MarkNoAccess;<br>confidential-access message])
```

## Failure and edge-case behavior

- A worker ID of zero or less is silently ignored: no context is created, `ChangeContext()` does not run, and no message is set for the caller — this differs from the explicit `PLEASEENTERCLAIM` messaging used by the claim-number and claim-ID overloads.*
- Because `GetClaimData()` only branches on `Context.ClaimID` and `Context.ClaimNumber`, and the worker-only `ClaimContext` constructor leaves `ClaimNumber` blank, a worker-context request resolves claim data through a blank claim-number lookup unless a subclass overrides `GetClaimData()` to use `Context.WorkerID` directly. Whether any subclass provides such an override could not be confirmed from this library's source.**
- All security-evaluation and no-access behavior described for [Set claim context](set-claim-context.md#failure-and-edge-case-behavior) applies identically once `ChangeContext()` begins.

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts. Statements marked with `**` could not be confirmed; treat
> as unknown until verified.

## Sources

- `Application\SAIF.Application.Claim\ClaimAppManager.vb`
- `Application\SAIF.Application.Claim\ClaimContext.vb`
- `Application\SAIF.Application.Claim\ClaimSecurity.vb`
- `Application\SAIF.Application.Claim\ClaimAppConstants.vb`