Running AMBA People.

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 and grades, (4) leave and payroll configuration, (5) go-live. Steps 1–4 can be revised at any time from Settings. Step 5 is a one-way transition. Once you go live, the system considers itself in production.

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. Every table with a business meaning carries an organisation_id, and every query filters by it. Cross-organisation reads are only available to Super Admin, and only through a specifically-scoped API surface.

Employee codes (ACME-EMP-0001, ORG-EMP-0042) are a computed field, populated via Postgres sequence at insert time. The prefix comes from organisation settings; the numeric portion is monotonic and gapless. Codes are never reused, even after offboarding. A returning employee gets a new code.

AMBA People implements six primary workflows, each modelled as a state machine: onboarding, leave request, payroll run, performance review, grievance, and offboarding. Every state transition writes an audit event with the actor, timestamp, and any contextual payload (e.g. the reason for a leave rejection).

The leave workflow is the simplest. Employee submits → manager reviews → approved or rejected. Payroll is the most complex. Ten states, four distinct approver roles, three sanity-check gates. The payroll workflow is documented in full in the Payroll Framework doc.

AMBA People integrates outward via HTTP webhooks and inward via a REST API. Webhook endpoints for common events (employee_created, payroll_paid, leave_approved) can be configured per organisation to POST to any URL you specify. Commonly used to sync into a general ledger, notify a Slack channel, or trigger a downstream provisioning job.

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. See the integration guide for the exact payload shape and authentication mechanism.

Six roles: Super Admin, HR Admin, Finance Approver, Manager, Employee, Executive. Permissions are enforced server-side via a decorator on every API endpoint. Frontend route guards and UI hiding are UX polish only. The authoritative check happens on the backend on every request.

A user can hold multiple roles. A department head who is also an executive holds both the Manager role (for their team) and the Executive role (for the aggregate dashboard). The most permissive applicable role wins per resource. But Employee-scoped resources (own data) always apply, no matter what else the user is.

Every mutating action writes to audit_logs. The table has INSERT permission only. Nobody, including Super Admin, can UPDATE or DELETE an audit row. This is enforced at the database level with a Postgres role, not at the application level, so a compromised application cannot rewrite history.

Audit entries capture actor (user ID), action (create / update / delete), resource (table and ID), before / after values for updates, timestamp, IP address, and user agent. Auditors are provisioned a read-only role scoped to the audit_logs table for the duration of the audit.

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.

At month-end, the payroll run consumes about half a day of HR + Finance time, concentrated on the variance review and approval steps. Institutions running AMBA for more than a year typically report that month-end HR work has shrunk from three days to about a day.