WP ERP HR persists the employee record in wp_erp_hr_employees linked to a person row in wp_erp_peoples. Leave requests live in wp_erp_hr_leave_requests with leave policies in wp_erp_hr_leave_policies and entitlements in wp_erp_hr_leave_entitlements. Department and designation references sit in wp_erp_hr_depts and wp_erp_hr_designations. The default HR UI lists employees on one screen and leave on another, which works for HR admins doing one task at a time and limits cross-screen operations.

SleekView reads wp_erp_hr_employees directly and joins wp_erp_peoples for name and email, wp_erp_hr_depts for department and wp_erp_hr_leave_requests aggregated for pending leave count. Filters combine department, designation, hire date and leave status in saved views. Leave approval becomes a single filtered table instead of a per-request screen walk.

Inline edits route through WP ERP HR's functions where supported, so leave approvals, status changes and designation updates call the same hooks the default UI fires. Audit entries in WP ERP's logs record consistently.

WP ERP HR shares people storage with CRM and Accounting because employees, customers and vendors often overlap in small-business operations. The HR schema layers wp_erp_hr_employees, wp_erp_hr_leave_requests, leave policies and entitlements on top of that shared base. The default HR admin keeps each concept on its own screen because that is the right shape for data entry and limits the chance of accidental edits across modules.

The cost is that HR teams routinely ask cross-screen questions: pending leave by department, balance by employee, attendance trends by team. SleekView reads the HR tables directly with the joins those questions need, surfaces leave balance and pending counts as columns, and routes inline approvals through WP ERP HR's functions so notifications and audit entries remain correct. HR admins keep org records tidy from one table.

Line managers approve a sprint's leave in one pass. People analytics gets export-ready cohorts without spreadsheet pivots. The shared schema was designed for this kind of joined view; SleekView is the working layer that uses it.