FAQ & Troubleshooting
The questions HR operators and employees ask most, the error messages you might see and what they mean, and a glossary of every term used in this guide.
Troubleshooting — common errors
| Message / symptom | Why it happens | What to do |
|---|---|---|
| "You have used all 3 mobility actions in the rolling 6-month window." | The employee has hit the mobility limit for the period. | Wait until an earlier application ages out of the window, or (if overrides are enabled) use Request exception. HR can raise movements_max_actions if the policy is too tight. |
| "That status change is not allowed from the opening's current status." | You tried a transition that isn't permitted (e.g. Published → Draft). | Follow the allowed path — see the transition table in the Reference. |
| "An identical movement already exists for this employee and effective date." | The idempotency key matched an existing row — usually a double-submit. | Nothing to do; the duplicate was safely prevented. The original row already reflects the change. |
| "Selection failed — all changes were rolled back." | A step in the one-transaction selection failed, so everything was undone. | Re-check the opening still has a free slot and the candidate still passes the policy, then try again. Nothing was partially applied. |
| Salary columns show "Hidden". | You don't hold movements_view_salary. |
Ask an admin to grant it, or accept that pay is intentionally masked for your role. |
| The HR Operations menu group doesn't appear. | The module is disabled, or your role lacks the relevant permission. | Enable Movements in Manage Modules and grant at least the base key for the surface you need. |
| Auto-capture ran but recorded no movements. | First run seeds baselines only, or nothing changed since the last run. | Expected. Movements appear on later runs after the Employee Master actually changes. |
Frequently asked questions
Employee movements are immutable audit events by design — editing history would defeat
the audit trail. To fix a wrong movement, open it and choose Reverse (correction),
which adds a linked correction row. Deletion exists (with movements_delete) only
for rows created entirely in error, and is discouraged in favor of a reversal.
No. A manual movement documents a change in the audit trail; it doesn't rewrite the Employee Master. The flow that updates the employee's department, position and salary and records the movement together is candidate selection in Internal Hiring.
The daily job keeps a per-employee snapshot (department + position + salary) and compares a hash of the current state to it. When they differ, it records a movement classified as a transfer, role change or salary adjustment, then updates the snapshot. The very first run only stores baselines and records nothing.
No. The portal and the "My Internal Applications" / "My Movement History" profile tabs are self-service for any active staff member — gated only by the module being enabled. Their identity is taken from the signed-in session, so they only ever see and act on their own data.
By default, yes — a withdrawn application keeps counting. If your company sets a
withdrawal grace window and you withdraw within that many hours of submitting, the
count is released (treating it as an erroneous submission). Your HR admin controls this with
movements_count_withdrawn and movements_withdrawal_grace_hours.
When an employee is blocked by a policy rule (limit, tenure, disciplinary) and overrides
are enabled, they can Request exception with a reason. It goes to HR (anyone with
mobility_override) as a pending request to approve or reject. An approved,
unexpired override lets that employee bypass the policy rules for that opening — but never the
structural rules (the opening must still be open; they still can't double-apply).
Two controls apply. The movements_view_salary permission reveals salary to
HR everywhere. The movements_salary_visibility setting decides the
employee's own view on the self-service tab: "HR only" hides their figures, "The employee and
HR" shows them their own salary changes.
Only when two switches agree: the tenant setting (movements_auto_post_announcement
/ _timeline) and the per-opening flag. Even then, if the target feature
isn't installed, publishing still succeeds and the post is simply skipped.
Yes. The migration runs against the primary and every tenant database, the settings are
tenant-scoped, and the cron jobs run per tenant. The demo seeder accepts
--tenant=<company_key> and --all.
Glossary
Getting help
If a screen behaves unexpectedly, check the module's system activity log first — every mutation is recorded there (see the log-event list), so you can see exactly who did what and when. If the behavior contradicts this guide, capture the exact message and the steps to reproduce it and raise it with your ERPat administrator or the module owner (support contact: ERPat Team).