All docsAMBA People · Documentation

Running AMBA People.

A working reference for HR Admins, IT operators, and anyone else who has to configure, operate, or troubleshoot AMBA People. Written to be read cover to cover on day one, and dipped into thereafter.

Getting started

A fresh AMBA installation opens directly into the setup wizard. There is no separate admin console for initial configuration. The wizard drives everything in a defined order. Skip a step at your peril; several later steps assume earlier ones are complete.

The five wizard steps: (1) module activation, (2) organisation identity, (3) departments, (4) leave types, (5) a final summary, where you add your first employee. These choices can be changed later from the portal.

Tip
Do the setup wizard on staging first. Import a subset of employees, run one payroll, audit the output, then repeat on production with the full workforce. This catches the usual data-quality issues in employee records before they affect daily work.

Data model

The employee record is the atom. Everything else. Payroll runs, leave requests, performance reviews, attendance events. Hangs off the employee row via foreign keys. If a downstream table has an employee_id, it observes the employee's active status, reporting line, and grade transparently.

The organisation is the tenant boundary for records such as users, employees and departments. Some reference data, such as leave types, is still shared rather than held per organisation, and some modules are not yet available to self-provisioned organisations.

Employee codes (ACME-EMP-0001, ORG-EMP-0042) are assigned when the employee is created. The prefix comes from organisation settings; the number increments from the last code issued under that prefix.

Workflows

AMBA People covers six primary workflows: onboarding, leave request, payroll run, performance review, grievance, and offboarding.

A payroll run moves through four statuses: draft, pending approval, approved, and paid. The payroll workflow is described in the Payroll Framework doc.

Integrations

Biometric device integration is inbound via HTTP POST. The device sends a JSON body with employee ID, timestamp, and event type. AMBA acknowledges and aggregates into the attendance record.

Roles and permissions

Eight roles: Super Admin, HR Admin, Finance, Manager, Employee, Executive, Legal, and IT Admin. Each user account holds one role. Role checks run on the server. Frontend route guards and UI hiding are UX only.

Audit log

Actions across the modules write to audit_logs. The application has no way to edit or delete audit rows. This is not yet enforced by database permissions.

Audit entries capture the actor, action, module, record ID, before and after values where the action provides them, timestamp, and IP address. Super Admins can review them in the audit log.

Day-to-day operations

Most weeks, an HR Admin will: onboard 0–5 new employees, approve or reject 5–20 leave requests, review the previous week's attendance for corrections, and (once a month) run payroll. AMBA is designed to make each of these routine. The dashboard surfaces exactly what needs attention.

This documentation covers AMBA People at a working reference level. Detailed API reference, schema documentation, and operational runbooks are provided as part of the implementation package.