---
title: SAIF.Business.Policy.Affiliate architecture
summary: Architectural responsibilities, boundaries, and interaction patterns for policy-affiliate business objects.
status: draft
owner: Technical Writer
last_reviewed: 2026-07-31
library: SAIF.Business.Policy.Affiliate
reference_type: package
---

# SAIF.Business.Policy.Affiliate architecture

`SAIF.Business.Policy.Affiliate` is a mid-tier BOF business-object library that models affiliates attached to a policy: interested parties, preferred workers, and corporate officer exemptions. It uses shared base classes to centralize association SQL and delegates lifecycle orchestration to framework data-portal services rather than managing connections or transactions directly.

## Responsibilities
- Model the `AFFILIATE` person entity and the `BUSINESS_AFFILIATE` policy-association entity.
- Differentiate interested parties and preferred workers by `AFFILIATE_TYPE_CODE` while reusing the same shared join fragments.
- Retrieve corporate officer exemptions as a separate result-set-based object family.
- Resolve code descriptions through framework code collections and expose nested affiliate objects where required.

## Component boundaries
- `clsAffiliate` (`clsBusinessBase`*): standalone person entity keyed by SSN.
- `clsPolicyAffiliateBase` / `clsPolicyAffiliateBaseCollection`: abstract templates that centralize association identity, joined affiliate hydration, and common retrieve criteria.
- `clsInterestedParty` / `clsInterestedPartyCollection`: concrete affiliate-type-`1` policy associations.
- `clsPolicyPreferredWorker` / `clsPolicyPreferredWorkerCollection`: concrete affiliate-type-`2` policy associations with a lazy eligibility lookup against `PREFERRED_WORKER`.
- `clsCorporateOfficerExemption` / `clsCorporateOfficerExemptionCollection`: exemption objects loaded through `clsResultSet` rather than `IDataReader`.

## Interaction model
- Standard BOF retrieve callbacks (`BeforeRetrieve` / `AfterRetrieve`) drive all keyed and collection retrievals except the preferred-worker eligibility lookup.
- `clsPolicyAffiliateBase.Fill` hydrates a nested `clsAffiliate` from the same joined row so callers receive the association and person together.
- `clsPolicyPreferredWorker.GetPreferredWorkerData` creates an application-layer portal request on first access to eligibility properties and selects the earliest qualifying eligibility row.
- All persistence-oriented SQL properties throw `ApplicationException`, so the library remains retrieve-only even when objects are editable in memory.

## Architecture diagram
The following diagram shows the affiliate/association hierarchy and its retrieve paths.

```mermaid
flowchart TD
  Caller[Caller] --> A1[clsAffiliate]
  Caller --> A2[clsInterestedPartyCollection]
  Caller --> A3[clsPolicyPreferredWorkerCollection]
  Caller --> A4[clsCorporateOfficerExemptionCollection]
  A2 --> Base[clsPolicyAffiliateBase<br>shared association logic]
  A3 --> Base
  Base --> Aff[clsAffiliate<br>nested hydration]
  A3 -. lazy lookup .-> Elig[GetPreferredWorkerData]
  A1 --> Portal["IDataPortalInfo / IDataAccess*"]
  Base --> Portal
  A4 --> Portal
  Elig --> Portal
  Portal --> Oracle[(Oracle)]
```

## Sequence diagram
The following diagram shows a representative interested-party collection retrieval.

```mermaid
sequenceDiagram
  participant Client
  participant Collection as clsInterestedPartyCollection
  participant Portal as IDataAccess*
  participant Oracle
  Client->>Collection: GetInterestedPartyCollection(portal, policy, start, end)
  Collection->>Portal: RetrieveObject(criteria)
  Portal->>Oracle: Execute joined BUSINESS_AFFILIATE + AFFILIATE SQL
  Oracle-->>Portal: IDataReader
  Portal-->>Collection: Row stream
  Collection->>Collection: Load child objects and optional cached code tables
  Collection-->>Client: Populated collection
```

## Design constraints
- The library is retrieve-only; no live create, insert, update, or delete SQL is exposed.
- Policy-affiliate queries surface personally identifying data such as SSN and date of birth, but no local authorization checks were found in this library.
- Interested-party and preferred-worker families use `IDataReader`-style loading, while corporate officer exemptions use `clsResultSet`, so two BOF result patterns coexist in the same package.

## Related documentation
- [Index](index.md)
- [Overview](overview.md)
- [Dependencies](dependencies.md)
- [Operations and processes](operations-processes.md)
- [Business rules](business-rules.md)
- [Database tables](database-tables.md)
- [SQL catalog](sql/index.md)
- [API reference](api/index.md)
- [Configuration](configuration.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
- `Business\SAIF.Business.Policy.Affiliate\clsAffiliate.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsPolicyAffiliateBase.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsPolicyAffiliateBaseCollection.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsInterestedParty.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsInterestedPartyCollection.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsPolicyPreferredWorker.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsPolicyPreferredWorkerCollection.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsCorporateOfficerExemption.vb`
- `Business\SAIF.Business.Policy.Affiliate\clsCorporateOfficerExemptionCollection.vb`