HCM setup · Antly Support

Settings Routes

Use these routes from Launchpad -> HCM or the relevant settings navigation. Route availability still depends on tenant permissions and feature access.

/settings/hcm-settings
/settings/employee-records
/settings/employee-fields
/settings/employee-directory
/settings/employee-bank
/settings/leave
/settings/pay-grade
/settings/salary
/settings/performance
/settings/training
/settings/exit-management

Prerequisites

Create tenant users for employees who need self-service access.
Configure departments, units, positions, locations, holidays, and reporting lines in Global Settings.
Decide which employee fields are core fields and which belong in dynamic employee sections/questions.
Define job roles and pay grades before importing salary-sensitive employee data.
Create leave types, leave balances, and leave approval rules before opening leave requests.
Agree which performance, training, and exit workflows are owned by HR versus managers.

Permissions To Plan

Separate administrators who can change settings from operators who can create and update daily records.
Give read-only access to reporting audiences instead of granting broad edit permissions.
Protect delete, void, post, refund, close, publish, approve, and status-changing actions behind trusted roles.
Review permissions for imported records, API keys, and workflow service users as carefully as UI users.
Check whether self-service users should see only their own records, their team records, or all tenant records.
Keep public or embedded routes limited to records intended for public exposure.
Use Base page permissions when a custom workspace should expose only part of the module.
Confirm reference/API access in /reference/hcm before handing credentials to an integration.

Recommended First-Time Checklist

Open Launchpad -> HCM and confirm the module loads for an administrator.
Create or confirm the global tenant data the module depends on: users, teams, locations, holidays, departments, currencies, or objects as applicable.
Visit each settings route listed above and decide which settings are required before go-live.
Create one realistic configuration record for each required setup area.
Create one realistic operational record and move it through its expected lifecycle.
Confirm list, detail, create, edit, approval, and report views behave correctly for administrator and normal user roles.
Configure at least one workflow notification or task for an important exception.
Check that reports show the pilot records with the expected filters and dimensions.
Check that JQL/API access is limited to the namespaces the integration or script actually needs.
Document who owns configuration, daily operation, reporting, and exception resolution.
Clean up pilot data or mark it clearly before importing production data.
Review audit/history surfaces after key actions so compliance users know where to look.

Validation Before Go-Live

A normal operator can create and update the records they own without seeing restricted settings.
An approver can approve or reject without gaining unnecessary administrator access.
A reporting user can read reports without changing source records.
A workflow can receive the expected payload and create a task, notification, approval, or related record.
A failed or rejected record remains visible with enough context to resolve it.
The module reference page matches the namespaces and intents planned for integrations.
Public, embedded, or portal routes expose only intentional data.
Imports, if used, preserve tenant ownership, status, owner, dates, and required relationships.
The team knows which records must never be deleted because they support audit or historical reporting.
Owners have a recurring review rhythm for settings and permissions.

Implementation Notes

Backend records come from src/hcm/models.py.
Frontend screens and settings were checked in packages/antly-app-hcm or the Base app routes listed above.
Automation and API details should be checked against /reference/hcm during implementation.
Keep configuration changes small at first; prove one complete lifecycle before importing or enabling broad access.
Use workflows for repeatable approvals and notifications rather than relying on manual reminders.
Use tasks for exceptions that need named ownership.
Use reports to confirm the setup is producing useful operational data.
Review permissions again after the first production week, when real usage patterns are visible.