---
title: Retrieve interested parties for a policy
summary: Operation details for Retrieve interested parties for a policy.
status: draft
owner: Technical Writer
last_reviewed: 2026-07-31
library: SAIF.Business.Policy.Affiliate
reference_type: package
operation_id: OP-004
trigger: A caller requests all interested parties that overlap a policy date window.
---

# Retrieve interested parties for a policy

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

| Field | Value |
| --- | --- |
| **Operation ID** | OP-004 |
| **Trigger** | A caller requests all interested parties that overlap a policy date window. |
| **Inputs** | `IDataPortalInfo`, policy number, optional start date, optional end date |
| **Outputs** | `clsInterestedPartyCollection` |
| **Primary components** | `clsInterestedPartyCollection.GetInterestedPartyCollection` |
| **Entry point** | `Business\SAIF.Business.Policy.Affiliate\clsInterestedPartyCollection.vb` |

## Steps

1. Build the collection criteria from the policy number and requested window, defaulting to the full date range when the single-parameter overload is used.
2. Assign [SQL-005](../sql/SQL-005-saif-business-policy-affiliate.md) in `BeforeRetrieve` and bind the policy and window parameters for [BUSINESS_AFFILIATE](../database-tables.md#business_affiliate) and [AFFILIATE](../database-tables.md#affiliate).
3. The query returns only type-`1` rows, applies overlap-window filtering, and sorts by affiliate name ([BR-AFF-003](../business-rules.md#br-aff-003-interested-party-queries-require-type-code-1), [BR-AFF-005](../business-rules.md#br-aff-005-association-windows-use-overlap-semantics), [BR-AFF-006](../business-rules.md#br-aff-006-association-lists-sort-by-person-name)).
4. Iterate the reader in `AfterRetrieve`, create a `clsInterestedParty` for each row, and load the child object from the shared joined result set.
5. When the portal is already inside a pending transaction, pass collection-cached title and insured code tables into each child load so the child does not issue nested code-table lookups ([BR-AFF-007](../business-rules.md#br-aff-007-transactional-loads-reuse-shared-code-collections)).
6. Return the populated collection.

## Process flow
The following diagram shows the overlap-window query and the transactional cached-code-table branch during child hydration.

```mermaid
flowchart TD
  Start(["Caller requests policy interested parties"]) --> Criteria["Build collection Criteria;<br>default full window if single-arg overload"]
  Criteria --> Before["BeforeRetrieve: assign SQL-005<br>bind policy + window against BUSINESS_AFFILIATE + AFFILIATE"]
  Before --> Query["Query returns type-1 rows,<br>overlap-window filtered, sorted by name"]
  Query --> Iterate["AfterRetrieve: iterate reader"]
  Iterate --> TxnCheck{"Pending transaction open?"}
  TxnCheck -->|Yes| Cached["Pass collection-cached InterestedPartyTitles<br>and InsuredCodes into child Load"]
  TxnCheck -->|No| PerChild["Child loads its own code-table lookups"]
  Cached --> AddChild["Create clsInterestedParty and add to collection"]
  PerChild --> AddChild
  AddChild --> More{"More rows?"}
  More -->|Yes| Iterate
  More -->|No| Result(["Return populated collection"])
```

## Failure and edge-case behavior

- The collection constructor enables edit/remove/find behavior in memory, but the collection still cannot persist changes through this library.

## 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\clsInterestedPartyCollection.vb`