Movements Overview Public

Movements

Overview of the ERPat Movements module — the HR Operations workspace for employee movement audit trails, internal hiring, and a self-service internal job portal governed by a configurable mobility policy.

Guide version: r1 Module version: 1.1.0 Updated: 2026-07-22 Estimated time: 4 min 1 views

Movements

The HR Operations workspace for internal mobility — track every department, position and salary change as an immutable audit trail, run internal hiring end-to-end, and give staff a fair, self-service job portal.

⇄ 1 "HR Operations" menu group ◈ 4 working surfaces ☑ 6 database tables ₱ Philippine-market ready

Movements is ERPat's internal-mobility and HR-operations module. It lives in the sidebar under a single HR Operations group and answers one question end-to-end: "When and how does a person's role, department or pay change — and who decided it?" Every change lands as an immutable movement record; managers post internal openings; and employees browse and apply through a self-service portal under a configurable mobility policy. It is a self-contained module — enable it in Settings and the whole workspace appears.

????
New here? Start with Getting Started to enable the module, run its migrations, and grant permissions. Then read Daily Operations for the click-by-click SOPs, and keep FAQ & Troubleshooting open while you learn the vocabulary.

What the module does

Movement audit & mobility

Employee Movement is a tamper-evident history of transfers, promotions, role and salary changes. Internal Hiring publishes openings and runs a candidate pipeline; the Internal Job Portal lets every employee apply under a fair, audited mobility policy. Selecting a candidate updates the employee record and writes the movement in one transaction.


Who this module is for

HR & People Operations

Record and reverse movements, publish and approve internal openings, run candidate pipelines, and tune the mobility policy. These users hold the Human Resource: Mobility permissions.

Every employee (staff)

The Internal Job Portal and the "My Movement History" and "My Internal Applications" profile tabs need no HR permission — any active staff member can browse published openings, see their own eligibility, apply, withdraw, and request an exception.

Explore the guide


The 60-second mental model

Change happens
Hire, transfer, promote, adjust pay
Recorded
Manually, from hiring, or auto-captured
Immutable
History never edited — only reversed
Visible
On the audit table & profile tabs
Auditable
Every action leaves a system log

A person's role, department or salary changes. Movements captures that as an immutable audit row — recorded three ways: an HR user records it manually, the internal hiring selection writes it automatically, or the daily auto-capture job notices the Employee Master drifted and records the difference. History is never edited; a mistake is fixed by recording a reversal (a correction row that points back at the original). Everyone with the right permission sees the trail on the audit table and each employee's profile, and every mutation also lands in ERPat's system activity log.

What ships out of the box

4
Menu items / surfaces
10
RBAC permissions
12
Mobility settings
2
Daily cron jobs

Enabling the module seeds a sensible default mobility policy (3 internal applications per rolling 6 months), registers 2 daily cron jobs (auto-capture at 02:20, close-expired openings at 01:10), adds 3 profile tabs to the team-member profile, a Mobility Settings tab inside core Settings, and a demo seeder you can load to explore every screen with sample data. All of it is described in Administration & Controls.

⚠️
The one rule that matters most: employee movements are immutable audit events. There is no "edit" — you record, view, reverse (a correction row) or delete (permission-gated). To fix a wrong movement, record a reversal; never treat the history as editable data.
????
Privacy by design. Salary columns are gated behind the movements_view_salary permission, the staff portal and the "My…" profile tabs resolve the employee from the signed-in session only (never a browser-supplied id), and what an employee can see about their own salary changes is controlled by the salary visibility setting. See Administration.
Was this guide helpful?

Report a content problem