SAIF.Business.Claim.Authority architecture

SAIF.Business.Claim.Authority is the claim-domain business library for financial authorization limits, grant authority, approval-type control, and supporting code tables for reserve and payment approvals.

Responsibilities

• Manage employee grant authority by business process.
• Persist business-function and category-change authorization limits.
• Validate reserve, payment, approval-type, and category authorization decisions.
• Load authority-purpose, authority-type, business-function, and business-process code maps.
• Enforce production-only restrictions on security overrides.

Component boundaries

• clsClaimAuthority is the aggregate root that coordinates grant-authority, business-function-limit, and category-change-limit child objects.
• Child collections encapsulate CRUD for authorization-limit rows.
• mdlClaimAuthority owns code-map retrieval for supporting lookup data.
• Direct scalar-query checks remain inside the authority library instead of being delegated to a separate service layer.
• Infrastructure security is out of scope; this library governs business dollar-authority, not application access control.

Interaction model

Administrative claim workflows create or retrieve a clsClaimAuthority aggregate for an employee, populate or validate child limit collections, execute direct Oracle checks for authorization decisions, and then save the aggregate graph back through BOF lifecycle methods. Supporting code maps are loaded on demand from claim authority tables.

Inherited framework context (from Legends CLI)

• IBusinessCriteria provides the CRUD-oriented SQL contract used by authority criteria objects and child limit entities.*
• IDataPortalInfo provides scalar and result-set execution paths plus portal routing for Oracle-backed authority lookups and saves.*
• clsBusinessBase provides the edit lifecycle and shared rules-manager model that authority objects use to validate limits, dates, and grant constraints.*
• clsBusinessCollectionBase provides traversal, deleted-item tracking, and aggregated validation behavior for authorization-limit collections.*

Architecture diagram

The following diagram shows the high-level authority-management architecture.

flowchart TD
    Consumer["Claim admin workflow"] --> Authority["clsClaimAuthority"]
    Authority --> AuthType["Grant authority child"]
    Authority --> BusFunc["Business-function limits"]
    Authority --> CatChange["Category-change limits"]
    Authority --> CodeMaps["mdlClaimAuthority code maps"]
    Authority --> DPI["IDataPortalInfo / IDataRequest"]
    CodeMaps --> DPI
    DPI --> Oracle["Oracle authority tables"]

Sequence diagram

The following diagram shows a representative authority-validation sequence.

sequenceDiagram
    participant Admin
    participant Authority as clsClaimAuthority
    participant DPI as IDataPortalInfo
    participant Oracle
    Admin->>Authority: Create(employee)
    Authority->>DPI: Retrieve existing authority and limits
    DPI->>Oracle: Select authority rows and code maps
    Oracle-->>DPI: Current authority data
    DPI-->>Authority: Hydrated child objects
    Admin->>Authority: CanAuthorizePayment(...)
    Authority->>DPI: Execute scalar authorization query
    DPI->>Oracle: Check max amount / approval type
    Oracle-->>Authority: Authorization result
    Authority-->>Admin: Allowed or denied

Design constraints

• The library mixes aggregate-child BOF persistence with direct scalar SQL for authorization decisions.
• Financial authority is claim-domain business logic and must remain separate from infrastructure AD-security decisions.
• Security override cannot be enabled in production.
• Code-table completeness directly affects validation and authorization outcomes.

Related documentation

• Index
• Overview
• Dependencies
• Operations and processes
• Business rules
• Database tables
• SQL catalog
• API reference

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.Authority\SAIF.BOF.Business.Claim.Authority.vbproj
• Business\SAIF.Business.Claim.Authority\SAIF.BOF.Business.Claim.Authority.nuspec
• Business\SAIF.Business.Claim.Authority\packages.config
• Business\SAIF.Business.Claim.Authority\clsClaimAuthority.vb
• Business\SAIF.Business.Claim.Authority\clsClaimEmpAuthType.vb
• Business\SAIF.Business.Claim.Authority\clsClaimEmpBusFuncLimit.vb
• Business\SAIF.Business.Claim.Authority\clsClaimEmpBusFuncLimitCollection.vb
• Business\SAIF.Business.Claim.Authority\clsClaimEmpCatChangeLimit.vb
• Business\SAIF.Business.Claim.Authority\clsClaimEmpCatChangeLimitCollection.vb
• Business\SAIF.Business.Claim.Authority\clsClaimAuthPurposeCode.vb
• Business\SAIF.Business.Claim.Authority\clsClaimAuthTypeCode.vb
• Business\SAIF.Business.Claim.Authority\clsClaimBusFunctionCode.vb
• Business\SAIF.Business.Claim.Authority\clsClaimBusProcessCode.vb
• Business\SAIF.Business.Claim.Authority\mdlClaimAuthority.vb