---
title: Claim authority initialization
summary: Loads an employee's grant authority, business function limits, and category change limits into a single authority aggregate, creating a default grant authority row if none exists yet.
status: draft
owner: Technical Writer
last_reviewed: 2026-07-30
library: SAIF.Business.Claim.Authority
reference_type: package
operation_id: OP-001
trigger: Caller invokes clsClaimAuthority.GetByMailID or GetByEmplID for a given business process
---

# Claim authority initialization

Claim authority initialization is the read path that assembles the full authorization picture for one employee within one business process (reserves or payments): the employee's own grant authority level, and the collections of business-function and category-change dollar limits that authority level allows them to grant to others. If the employee has never been granted an authority level, `Create()` seeds a default, in-memory `CanNotAuthorizeOthers` row rather than failing.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-001 |
| **Trigger** | `clsClaimAuthority.GetByMailID(dpi, mailId, busProcessCode)` or `GetByEmplID(dpi, emplId, busProcessCode)` (also overloaded to accept the `BusinessProcesses` enum) |
| **Inputs** | `EmplID` or `MailID`, `BusinessProcessCode` (`"1"` reserves / `"2"` payments) or `BusinessProcesses` enum value |
| **Outputs** | Populated `clsClaimAuthority` with `Employee`, `AuthorizingEmployee`, `GrantAuthority`, `AuthorizingGrantAuthority`, `BusinessFunctionLimits`, and `CategoryChangeLimits` |
| **Primary components** | `clsClaimAuthority.Create`, `clsClaimAuthority.GetByMailID`, `clsClaimAuthority.GetByEmplID` |
| **Entry point** | `Business\SAIF.Business.Claim.Authority\clsClaimAuthority.vb` |

## Steps

1. **Resolve the criteria.** `GetByMailID` first resolves the mail ID to an employee record and builds a `Criteria` from the resolved `EmplID` and the business-process code (or enum); `GetByEmplID` builds the `Criteria` directly from the supplied employee ID. Both overloads hand the criteria to the data portal, which invokes `Create()`.*
   - The employee lookup used by `GetByMailID` is provided by `clsEmployeeData` in the `SAIF.BOF.Business` package dependency; this library does not document that lookup's own operations.*
2. **Load the subject employee.** `Create()` sets `EmplID` from the criteria and retrieves the employee record via `clsEmployeeData.GetDataByEmployeeID`, then derives the employee's mail ID (trimmed, upper-cased) for later use.*
3. **Load the acting (authorizing) employee.** `Create()` resolves the caller's own employee record via `clsEmployeeData.GetDataByMailID`, using the trimmed, upper-cased `UserID` from the data-portal info. This is the employee whose own authority ceiling will later gate any changes ([BR-002](../business-rules.md#br-002-cannot-grant-authority-level-higher-than-own)).
4. **Load the acting employee's grant authority.** `AuthorizingGrantAuthority` is populated via `clsClaimEmpAuthType.GetClaimEmpAuthType(dpi, businessProcessCode, authorizingEmployee.ID)` ([CL_CLAIM_EMP_AUTH_TYPE](../database-tables.md#cl_claim_emp_auth_type)).
5. **Load the subject employee's grant authority.** `GrantAuthority` is populated the same way, keyed by the subject employee's ID ([CL_CLAIM_EMP_AUTH_TYPE](../database-tables.md#cl_claim_emp_auth_type)).
   - If the retrieved `GrantAuthority` is not valid (no row exists for this employee and business process): `clsClaimEmpAuthType.NewClaimEmpAuthType` creates a new, in-memory grant-authority object defaulted to `CAN_NOT_AUTHORIZE_OTHERS`. It is not persisted until [Claim authority save](claim-authority-save.md) runs.
6. **Load the business function limits collection.** If the resolved `ClaimBusProcessCode.IsReserve` is true, `clsClaimEmpBusFuncLimitCollection.GetReserveLimits` retrieves the reserve-scoped rows; otherwise `GetPaymentLimits` retrieves the payment-scoped rows for the same employee. Either call issues the same parameterized retrieve keyed by employee and business-process code. See [Business function limit maintenance](business-function-limit-maintenance.md) for the retrieval and per-row validation detail.
7. **Load the category change limits collection.** `clsClaimEmpCatChangeLimitCollection.GetClaimEmpCatChangeLimits` retrieves all category-change-limit rows for the employee, independent of business process. See [Category change limit maintenance](category-change-limit-maintenance.md) for the retrieval and per-row validation detail.
8. **Register children and mark clean.** `AddChildObject` registers the business function limits, category change limits, and grant authority as children of the authority aggregate, then `MarkClean()` and `MarkOld()` reset dirty/new state so the freshly loaded object reports as unmodified until the caller edits it.

## Process flow

The following diagram visualizes the initialization sequence.

```mermaid
flowchart TD
	Start([Caller requests authority<br>by mail ID or employee ID]) --> ResolveEmp[Load subject employee]
	ResolveEmp --> ResolveAuth[Load acting/authorizing employee]
	ResolveAuth --> LoadAuthGrant[Load acting employee's<br>grant authority]
	LoadAuthGrant --> LoadGrant[Load subject employee's<br>grant authority]
	LoadGrant --> GrantExists{Grant authority row exists?}
	GrantExists -->|No| NewGrant[Create in-memory default:<br>CanNotAuthorizeOthers]
	GrantExists -->|Yes| Limits
	NewGrant --> Limits[Determine business process]
	Limits --> Reserve{IsReserve?}
	Reserve -->|Yes| ResLimits[Load reserve<br>business function limits]
	Reserve -->|No| PayLimits[Load payment<br>business function limits]
	ResLimits --> CatLimits[Load category<br>change limits]
	PayLimits --> CatLimits
	CatLimits --> Clean[Register children;<br>MarkClean, MarkOld]
	Clean --> Done([Populated clsClaimAuthority<br>returned to caller])
```

## Failure and edge-case behavior

- A missing grant-authority row is not an error: the object is initialized in-memory with the most restrictive authority (`CanNotAuthorizeOthers`) rather than raising an exception.
- If the acting employee cannot be resolved from the data-portal's `UserID` (for example, the caller's mail ID does not match any employee), the subsequent `AuthorizingGrantAuthority` lookup would operate against an invalid employee ID; this path is not explicitly guarded in `Create()`.*
- `BusinessProcessCode` and the `BusinessProcesses` enum are two representations of the same value; passing an inconsistent pair across the two `GetBy*` overloads is not defended against beyond the code-map lookup performed in the `Criteria` constructor.

## 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.

## Sources
- `Business\SAIF.Business.Claim.Authority\clsClaimAuthority.vb`
- `Business\SAIF.Business.Claim.Authority\clsClaimEmpAuthType.vb`
- `Business\SAIF.Business.Claim.Authority\clsClaimEmpBusFuncLimitCollection.vb`
- `Business\SAIF.Business.Claim.Authority\clsClaimEmpCatChangeLimitCollection.vb`
- `Business\SAIF.Business.Claim.Authority\clsClaimBusProcessCode.vb`