---
title: Employee leave management
summary: Creates, retrieves, lists, updates, and deletes employee leave records while enforcing the library's leave validation rules.
status: draft
owner: SAIF
last_reviewed: 2026-07-30
library: SAIF.Business
reference_type: package
operation_id: OP-SB-03
trigger: Caller creates or maintains an employee leave record.
---

# Employee leave management

This operation manages `EMPLOYEE_LEAVE` rows through a mix of direct retrieval SQL and `pk82029_titan` package calls. The business object validates required fields and date boundaries before any write path executes.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-SB-03 |
| **Trigger** | Caller invokes leave factories or persists a `clsEmployeeLeave` object. |
| **Inputs** | Leave sequence, employee ID, investigator, reason, begin/end dates, system type, update user |
| **Outputs** | `clsEmployeeLeave`, `clsEmployeeLeaveCollection`, or write success/failure state |
| **Primary components** | `clsEmployeeLeave.NewEmployeeLeave`, `clsEmployeeLeave.Criteria.BeforeRetrieve`, `clsEmployeeLeave.BeforeInsert`, `clsEmployeeLeave.BeforeUpdate`, `clsEmployeeLeave.BeforeDelete`, `clsEmployeeLeaveCollection.GetEmployeeLeave` |
| **Entry point** | `Business\SAIF.Business\clsEmployeeLeave.vb` |

## Steps

1. New-record creation allocates a fresh leave sequence from the framework, stamps the current system type, and initializes create metadata before the object is returned to the caller.
2. `Validate` blocks persistence unless investigator, reason, begin date, and end date are all populated ([BR-SB-001](../business-rules.md#br-sb-001-employee-leave-requires-investigator-reason-begin-date-and-end-date)).
3. The same validation path rejects begin dates earlier than `1753-01-01`, rejects end dates earlier than today, and rejects begin dates later than end dates ([BR-SB-002](../business-rules.md#br-sb-002-employee-leave-dates-must-stay-within-allowed-ranges-and-ordering)).
4. Single-record retrieval builds a direct SQL statement keyed by `leave_sequence_num` and hydrates the business object from `EMPLOYEE_LEAVE` when the row exists ([SQL-027](../sql/SQL-027-employee-leave-retrieval.md), [EMPLOYEE_LEAVE](../database-tables.md#employee-leave)).
5. Collection retrieval packages the employee ID, system type, and current start date into `pk82029_titan.select_employee_leave` and materializes the returned rows into a `clsEmployeeLeaveCollection` ([SQL-028](../sql/SQL-028-pk82029-titan-select-employee-leave.md), [EMPLOYEE_LEAVE](../database-tables.md#employee-leave)).
6. Insert persistence sends the validated object state to `pk82029_titan.Insert_employee_leave`, which writes the new `EMPLOYEE_LEAVE` row ([SQL-002](../sql/SQL-002-pk82029-titan-insert-employee-leave.md), [EMPLOYEE_LEAVE](../database-tables.md#employee-leave)).
7. Update persistence calls `pk82029_titan.update_employee_leave`, passes the current `UpdateUser`, and expects the package to report one affected row ([SQL-046](../sql/SQL-046-pk82029-titan-update-employee-leave.md), [EMPLOYEE_LEAVE](../database-tables.md#employee-leave), [BR-SB-013](../business-rules.md#br-sb-013-employee-leave-updates-expect-single-row-success)).
   - If the package does not return exactly one updated row, the object treats the save as a failure.
8. Delete persistence calls `pk82029_titan.delete_employee_leave` and also expects a single-row success result ([SQL-047](../sql/SQL-047-pk82029-titan-delete-employee-leave.md), [EMPLOYEE_LEAVE](../database-tables.md#employee-leave), [BR-SB-014](../business-rules.md#br-sb-014-employee-leave-deletes-expect-single-row-success)).
   - If the delete result is not one row, the caller receives a failure state instead of silent success.
9. When the caller asks for the related employee object, the leave entity resolves it through `clsEmployeeData.GetDataByEmployeeID`, allowing directory metadata to be displayed alongside the leave record.

## Process flow

The following diagram visualizes this operation's control flow.

```mermaid
flowchart TD
    Start([Leave request]) --> Validate[Validate required fields and dates]
    Validate --> Valid{Validation passed?}
    Valid -->|No| Reject([Return broken rules])
    Valid -->|Yes| Action{Retrieve or write?}
    Action -->|Retrieve| Read[Run direct SQL or package select]
    Action -->|Insert| Insert[Call insert package]
    Action -->|Update| Update[Call update package]
    Action -->|Delete| Delete[Call delete package]
    Read --> Return1([Return leave data])
    Insert --> Return2([Return persisted leave])
    Update --> Return3([Return update result])
    Delete --> Return4([Return delete result])
```

## Failure and edge-case behavior

- Missing investigator, reason, or date fields stop the operation before any database write occurs ([BR-SB-001](../business-rules.md#br-sb-001-employee-leave-requires-investigator-reason-begin-date-and-end-date)).
- Out-of-range or reversed dates are rejected before insert or update processing ([BR-SB-002](../business-rules.md#br-sb-002-employee-leave-dates-must-stay-within-allowed-ranges-and-ordering)).
- Update and delete paths treat non-`1` row counts as failures because the object expects exactly one affected row ([BR-SB-013](../business-rules.md#br-sb-013-employee-leave-updates-expect-single-row-success), [BR-SB-014](../business-rules.md#br-sb-014-employee-leave-deletes-expect-single-row-success)).

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