AL development
HRMS for Microsoft Dynamics 365 Business Central: Employee Leave & Asset Management Extension
A Business Central extension written in AL that turns the standard Employee card into a lightweight HR system. It adds organizational structure (departments, positions, hierarchy), employment history, and a leave management module with balances and approvals built on Business Central’s standard approval engine. It also adds an asset management module that tracks company equipment through assignment, return and disposal, with a permanent audit trail. The business rules are centralized in codeunit
Watch Solution Demo Video Project Documentation
- Business Central AL
Overview
The solution has two modules that share one foundation:
Core HR foundation: HR Setup (number series and leave defaults), HR Department, HR Position, Employee Hierarchy, Employment History and Holiday Calendar. The Employee table is extended with department, position, manager, employment type and status, grade, cost center, date of joining and an approver user ID.
Leave management: leave types and categories (Annual, Sick, Maternity and others), per-employee leave balances (opening, earned, used, adjustments, closing), a leave request document with a subform, approval routing, and a leave ledger.
Asset management: an asset register with categories, assignments, returns and a history ledger. Assets are tracked by type (Laptop, Vehicle, Phone and others), status and condition.
Surfacing: an Employee card extension shows assigned assets, and there are three reports: Asset Register, Assignments by Employee and Employee Leave Balance.
Business problem
Many organizations that run Business Central for finance keep HR processes in spreadsheets, email or disconnected tools. That causes several problems:
Leave: requests are approved informally, balances drift out of sync, and there’s no reliable record of who approved what or how much leave is left.
Assets: laptops, phones, vehicles and access cards are issued with no single source of truth. Companies can’t easily say who holds an item, what condition it was in when issued or returned, or whether an item was lost or damaged and by whom.
Setup: new employees are often missing a leave balance. Employee data is split between HR and the ERP, and approvals live outside the system of record.
Audit: without a ledger, disputes over damaged or missing equipment and over leave entitlement are hard to resolve.
Solution and architecture
Architecture: a layered, in-ERP design. Data lives in custom tables and extensions of the native Employee table. Business logic lives in dedicated codeunits. Pages sit on top, and reports read from the same tables.
LayerContentsDataTables for HR structure, leave, assets, and setup; Employee table extensionBusiness logicAsset Management, Asset History Mgmt, Leave Request Approval Mgmt, HR Employee Mgmt codeunitsPresentationCard, list, document and subform pages; Employee card page extensionReportingThree RDLC-based reportsSecurityHRMS ASSET permission setQualityAsset Mgmt Tests codeunit
Key design decisions:
Native approval integration: leave requests use BC’s standard Approval Entry table. Approvals therefore appear on the built-in Requests to Approve and Approval Entries pages, and users don’t need a separate inbox.
Document lifecycle with state machines:
Leave: Open → Pending Approval → Approved/Rejected (plus Cancelled).
Assignment: Draft → Active → Returned.
Returns can be reversed.
Single point of truth for rules: table triggers delegate to codeunits, so rules apply the same way from a page, an API call or a test.
Immutable audit ledger: every asset event goes through one entry point (
LogEntry) into the Asset History Entry table, with from/to status and condition, employee, user and timestamp.Automation: a leave balance is created automatically when an employee is created.
Technical implementation
Built as a native extension of Business Central. Rather than a standalone application, the system extends the ERP’s own Employee record and reuses its built-in number series, approval engine, user setup and security model. HR data therefore lives next to finance data, and users work in an interface they already know.
Leave management
Request and validation: when an employee is selected on a leave request, their name and designated approver are filled in automatically. As soon as the dates are entered, the system calculates the number of days and checks them against the employee’s available balance, blocking requests that exceed it.
Approval routing: submitting a request creates an entry in Business Central’s standard approval system. Approvers see it in their normal “Requests to Approve” inbox and can open the request directly from there. Duplicate submissions are prevented, and a pending request can be cancelled and returned to draft.
Automatic balance update: approving a request updates the status and deducts the days from the employee’s balance. Rejection simply closes the request without touching the balance.
Balances from day one: every new employee automatically receives a leave balance record with an opening entitlement, so HR never has to set it up manually.
Asset management
Controlled lifecycle: assets move through a defined flow. An assignment starts as a draft, becomes active when confirmed, and ends as returned. Nothing changes on the asset until confirmation, so users can prepare an assignment safely.
Assignment rules: an asset can only be assigned if it is available, the employee exists, and it isn’t already assigned to someone else. On confirmation, the asset is marked as assigned, linked to the employee, and its condition at handover is recorded.
Return rules: a return must reference an active assignment and cannot be dated before the handover or entered twice. The asset’s new status follows what the return reports: lost, damaged, under repair, or back in the available pool. Mistaken returns can be reversed, provided the asset hasn’t been reassigned in the meantime.
Protected data: status, current holder and active assignment are system-maintained, so users can’t edit them by hand and break consistency. Manual status or condition changes, such as repair, disposal or location transfer, go through controlled actions.
Audit trail: every significant event writes a permanent history record: registration, assignment, return, transfer, repair, disposal and condition changes. Each records the asset, the employee, before and after status and condition, who did it and when. This gives a complete, tamper-resistant history for any item.
Design principles
Business rules in one place: validation and process logic are centralized rather than scattered across screens, so rules behave identically whether triggered from a page, an integration or an automated test.
Live figures, no duplication: values such as available leave balance and the number of assets an employee currently holds are calculated on demand from source records, so they can’t go stale.
Standard-first: reusing platform features for approvals, numbering and permissions reduces custom code, eases upgrades and keeps behavior familiar to users.
Reporting and security
Three printable reports cover the asset register, assets by employee and employee leave balances, each with filters such as employee, leave type or year.
A dedicated permission set controls who can access the asset module.
Quality assurance
The asset module is covered by automated tests that exercise the main scenarios: registering and assigning assets, rejecting invalid assignments and returns, handling damaged and lost equipment, protecting assigned assets from status changes, and reversing returns.