---
title: Vocational coordinators
summary: Resolves and caches the vocational reference lists — coordinators, rehab providers, counselors, statuses, and status details — and validates a vocational detail against them.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Maintenance
reference_type: package
operation_id: OP-CM-06
trigger: Any read of clsVocationalDetail.CoordinatorsList or CoordinatorName, or evaluation of the vocational detail's business rules during validation
---

# Vocational coordinators

Vocational coordinators is the reference-data and validation side of a vocational detail. Reading a coordinator, provider, counselor, status, or status-detail list resolves process-wide lookup data that is cached in shared variables for the lifetime of the application domain, and the object's rule set then requires the selected codes on a dirty record to resolve against those cached lists. None of these lookups is claim-specific, and none of the rules involved is registered in the library's catalogued business rules.*

| Field | Value |
| --- | --- |
| **Operation ID** | OP-CM-06 |
| **Trigger** | A getter reads `CoordinatorsList`, `CoordinatorName`, or a sibling reference list, or the framework evaluates the vocational detail's rules during validation |
| **Inputs** | Data-portal info taken from the object's criteria; no caller-supplied parameters — the coordinator, provider, status, and status-detail lookups are process-wide reference data |
| **Outputs** | A cached dictionary of coordinator code to coordinator user; a derived coordinator display name; a cached provider-location collection for rehab providers and counselors; a cached dictionary of status codes and names; a cached list of status-detail code, status code, and description rows; broken rules when a selected code does not resolve |
| **Primary components** | `clsVocationalDetail` (`CoordinatorsList`, `CoordinatorName`, `GetCoordinatorList`, `GetRehabProviderList`, `CounselorList`, `StatusList`, `StatusName`, `StatusDetailList`, `GetStatusList`, `GetStatusDetailList`, `AddBusinessRules` and its rule methods), `clsVocationalStatusDetail` |
| **Entry point** | `Business\SAIF.Business.Claim.Maintenance\clsVocationalDetail.vb` |

## Steps

1. **Request the coordinator list.** A getter or rule evaluation reads `CoordinatorsList`, which calls the shared helper `GetCoordinatorList` with the criteria's data-portal info; the cache is checked before any database access.
2. **Populate the cache on first use.** When the shared coordinator dictionary is still empty, call the code-list helper against the vocational package's coordinator entry point, keyed by the code column and valued by the coordinator user column, flagged as a stored-procedure call.*
3. **Execute the lookup.** The code-list helper runs the stored procedure through the standard request and cursor pattern and materializes the returned rows into a dictionary of code to coordinator user.
4. **Reuse the cache.** Because the dictionary is declared shared, it lives for the lifetime of the process, so later calls from any vocational-detail instance skip the round trip entirely.
5. **Resolve the coordinator name.** `CoordinatorName` looks the object's responsibility code up in the cached dictionary and returns the coordinator's display name, or an empty string when the code does not resolve.
6. **Validate the responsibility code.** When the object is dirty, the coordinator rule requires a non-blank responsibility code that resolves to a known coordinator name; otherwise it reports that a coordinator is required.*
7. **Resolve and validate the rehab provider.** The rehab-provider list caches a provider-location retrieval for the vocational provider type, filtered to locations with a non-empty physical address; the provider rule then requires a selected rehab-provider location, when one is chosen, to appear in that cached list.*
   - Sub-step: the provider-location retrieval loads the vocational provider locations and their addresses, which this operation only filters and caches.

   > **Origin**: `clsProviderLocationCollection.GetProviderLocations` is implemented in `SAIF.BOF.Business.View.Provider` and executed on behalf of this operation. That library is documented in the previous format, so no per-operation page exists; see [Operations and processes](../../saif-business-view-provider/operations-processes.md) in the `SAIF.BOF.Business.View.Provider` documentation set.
8. **Derive and validate the counselor.** The counselor list is derived from the selected rehab provider's related provider locations filtered to the vocational provider type, and is computed only when a rehab provider is set.
   - The counselor rule requires a selected counselor location to appear in that filtered list, short-circuiting when the list is not available.
   - A companion rule requires a rehab provider to be selected whenever a counselor is selected.*
9. **Resolve and validate the status code.** The status list caches an inline select of code and description from the `VOCATIONAL_STATUS_CODE` lookup table, ordered by description; the status rule requires a non-blank status code that resolves to a name when the object is dirty. That lookup table is not catalogued in the library's SQL or table inventories.*
10. **Resolve and validate the status detail.** The parameterless status-detail helper caches an inline select of all rows from the `VOCATIONAL_STATUS_DETAIL_CODE` table, and the status-scoped overload filters that cached list in memory to rows whose status code matches the current status or is blank.*
    - Each row is materialized as a status-detail object carrying code, status code, and description.
    - The status-detail rule requires a non-blank, resolvable status detail only when more than one option exists for the current status code.
11. **Validate the status date.** A further rule requires the status date, when the object is dirty, to fall between 1 January 1850 and thirty days from today; it performs no data access.
12. **Register and evaluate the rules.** All of these rules are registered once per instance from both constructors and are evaluated whenever the framework runs validation — typically before a caller attempts to save the vocational detail.

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
	Start([Getter or rule reads<br>a vocational reference list]) --> Which{Which list?}
	Which -->|Coordinators| CCache{Shared cache populated?}
	Which -->|Rehab providers| PCache{Shared cache populated?}
	Which -->|Statuses| SCache{Shared cache populated?}
	Which -->|Status details| DCache{Shared cache populated?}
	Which -->|Counselors| Prov{Rehab provider selected?}
	CCache -->|No| CLoad[Call coordinator<br>stored procedure via code-list helper]
	CCache -->|Yes| Use[Return cached list]
	PCache -->|No| PLoad[Retrieve vocational provider locations<br>with a physical address]
	PCache -->|Yes| Use
	SCache -->|No| SLoad[Inline select of<br>vocational status codes]
	SCache -->|Yes| Use
	DCache -->|No| DLoad[Inline select of<br>vocational status details]
	DCache -->|Yes| Use
	Prov -->|No| NoList[Counselor list unavailable]
	Prov -->|Yes| Derive[Filter provider's related<br>locations to vocational type]
	CLoad --> Use
	PLoad --> Use
	SLoad --> Use
	DLoad --> Use
	Derive --> Use
	NoList --> Rules
	Use --> Rules{Object dirty?}
	Rules -->|No| Skip([Rules not evaluated])
	Rules -->|Yes| Check[Require coordinator, status,<br>status detail, status date,<br>provider, and counselor to resolve]
	Check --> Result{All resolve?}
	Result -->|No| Broken([Broken rules reported;<br>object invalid])
	Result -->|Yes| Valid([Object valid])
```

## Failure and edge-case behavior

- The vocational package was not found in the Oracle catalog during retrieval; if the package is genuinely absent in a given environment, the coordinator lookup would fail at execution time with a database error rather than returning a graceful empty result.**
- Shared caching means the first data-portal info — and therefore the first connection and tenant context — used to populate each list determines the data for the rest of the process lifetime; reference-data changes are not reflected until the process restarts.*
- The coordinator, status, and status-detail name resolvers return an empty string rather than throwing when the current code does not resolve, silently masking bad or stale codes in read-only display scenarios.
- The status-detail rule is enforced only when more than one status-detail option exists for the current status, so a blank status detail passes validation for a status with zero or one option even though its resolved name may be empty.
- The counselor list is computed only when a rehab provider is set; the counselor rule guards against the missing list before testing membership.
- All of these rules evaluate only when the object is dirty, so a record loaded from the database and never modified is not re-validated even if the underlying reference data has since become stale or invalid.

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.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.Claim.Maintenance\clsVocationalDetail.vb`
- `Business\SAIF.Business.Claim.Maintenance\clsVocationalStatusDetail.vb`