---
title: Load preferred-worker eligibility
summary: Operation details for Load preferred-worker eligibility.
status: draft
owner: Technical Writer
last_reviewed: 2026-07-31
library: SAIF.Business.Policy.Affiliate
reference_type: package
operation_id: OP-007
trigger: A preferred-worker eligibility property is read for the first time and the cached eligibility fields are empty.
---

# Load preferred-worker eligibility

This operation documents how `clsPolicyPreferredWorker.GetPreferredWorkerData` fulfills the policy-affiliate behavior described for `SAIF.Business.Policy.Affiliate`.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-007 |
| **Trigger** | A preferred-worker eligibility property is read for the first time and the cached eligibility fields are empty. |
| **Inputs** | Affiliate SSN, effective date, cancel date from the current preferred-worker object |
| **Outputs** | Preferred-worker identifier, contract type, and eligibility dates |
| **Primary components** | `clsPolicyPreferredWorker.GetPreferredWorkerData` |
| **Entry point** | `Business\SAIF.Business.Policy.Affiliate\clsPolicyPreferredWorker.vb` |

## Steps

1. Build an application-layer portal request directly from the objects `DataPortalInfo` instead of using the normal BOF retrieve lifecycle.
2. Assign [SQL-007](../sql/SQL-007-saif-business-policy-affiliate.md) and bind `:AffiliateID`, `:EffectiveDate`, and `:CancelDate` for [PREFERRED_WORKER](../database-tables.md#preferred_worker).
3. Require the returned eligibility row to cover both the association effective date and the association cancel date ([BR-AFF-010](../business-rules.md#br-aff-010-eligibility-rows-must-cover-both-effective-and-cancel-dates)).
4. Order qualifying rows by eligibility-effective date and take the first one, so the earliest matching eligibility row wins ([BR-AFF-011](../business-rules.md#br-aff-011-earliest-qualifying-eligibility-row-wins)).
5. If no row is returned, cache sentinel values rather than retrying the lookup on every later property read ([BR-AFF-012](../business-rules.md#br-aff-012-missing-eligibility-returns-sentinel-values)).

## Process flow
The following diagram shows the lazy application-layer lookup, the covering-window filter, the earliest-row tiebreak, and the sentinel fallback.

```mermaid
flowchart TD
  Start(["Eligibility property read for the first time"]) --> Request["Build application-layer portal request<br>bypassing BeforeRetrieve/AfterRetrieve"]
  Request --> Bind["Assign SQL-007;<br>bind AffiliateID, EffectiveDate, CancelDate against PREFERRED_WORKER"]
  Bind --> Cover{"Any row covers both<br>effective and cancel dates?"}
  Cover -->|Yes, possibly multiple| Order["Order qualifying rows by eligibility-effective date;<br>take earliest via rownum = 1"]
  Cover -->|No| Sentinel["Cache sentinel values:<br>empty ID/contract type, Date.MinValue dates"]
  Order --> Cache["Cache PreferredWorkerID, ContractType,<br>and eligibility dates"]
  Sentinel --> Result(["Return cached eligibility state"])
  Cache --> Result
```

## Failure and edge-case behavior

- The request bypasses `BeforeRetrieve`/`AfterRetrieve`; any cross-cutting behavior attached only to those callbacks does not participate in this lookup.

## Related documentation
- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

## Sources
- `Business\SAIF.Business.Policy.Affiliate\clsPolicyPreferredWorker.vb`