HCM overview

Product Purpose

HCM manages the employee lifecycle from employee records and organisational placement through leave, salary data, performance, training, timesheets, announcements, social feed, and exit management.

HCM is a launchpad module, but it is not isolated from the rest of Antly. It shares tenant identity, permissions, workflow automation, reports, pages, and JQL access with Base so teams can run the module as part of a wider operating system rather than as a separate silo.

Use this overview when deciding what belongs in the module, what should stay in Base objects, and how the module should connect to tasks, tickets, workflows, pages, and reports.

Entity Table

Area	Source entities	Why it matters
People and employment	Employee, EmploymentHistory, EmployeeEducation, EmployeeDependant, EmployeeReference	Core worker profile, personal data, career history, and supporting references.
Compensation and structure	EmployeeSalary, EmployeeBank, PayGrade, PayGradeStep, JobRole	Salary records, pay grade placement, bank details, and role-based grouping.
Leave management	LeaveType, LeaveBalance, LeaveAccrual, LeaveRequest, LeavePolicy	Leave catalogue, balances, accrual, requests, and approval policies.
Performance and goals	PerformanceReviewTemplate, PerformanceReview, ReviewerAssignment, Goal, GoalUpdate, GoalMilestone	Review cycles, reviewer input, employee goals, progress, and milestones.
Training and enablement	TrainingCourse, CourseSection, CourseLesson, Quiz, TrainingEnrollment, TrainingPlan	Learning content, enrollments, plans, quizzes, and completion tracking.
Exit, communications, time	ExitProcess, OffboardingChecklist, Announcement, SocialPost, Timesheet, TimesheetEntry	Offboarding, company announcements, employee feed, and timesheet capture.
Configuration	EmployeeSection, EmployeeQuestion, HCMSettings	Dynamic employee fields and tenant-level HCM configuration.

How It Connects To Base

• Objects and records: Module records can be referenced from Base objects or can enrich object-backed workflows when teams need a tailored schema.
• Tasks: Operational exceptions, approvals, handoffs, and reminders should create tasks with owners and due dates.
• Tickets: Customer-facing or service-desk follow-up can be represented as tickets when the work needs queueing, SLA, or support ownership.
• Workflows: Create/update/status events can trigger approvals, notifications, cross-module updates, and scripted transformations.
• Pages and sites: Internal pages, portals, and public surfaces can expose selected module data when permissions allow it.
• Reports: Module reports should be combined with Base reports when leaders need cross-functional visibility.
• Reference: API and automation details live in /reference/hcm.

Launchpad Path And Routes

• Open the module from Launchpad -> HCM.
• Frontend source reviewed: packages/antly-app-hcm.
• Backend source reviewed: src/hcm/models.py plus controllers or automation files where available.
• Main route: /employees
• Main route: /people
• Main route: /leave
• Main route: /performance
• Main route: /training
• Main route: /timesheets
• Main route: /announcements
• Main route: /exit
• Main route: /salary

Who Uses It

• HR administrators.
• People operations teams.
• Managers and reviewers.
• Employees using self-service.
• Finance and payroll teams consuming salary or timesheet data.

What To Keep In This Module

• Use HCM for the records listed above when users need the module screens, module actions, and module reports.
• Use Base objects when the data is a tenant-specific schema that does not need module-specific lifecycle actions.
• Use tasks for human follow-up that needs an owner, due date, comments, or completion tracking.
• Use tickets for support or service work that benefits from queues, requesters, SLA thinking, or customer conversation history.
• Use workflows when a record change should notify people, request approval, create related work, or synchronize another module.
• Use pages when a role needs a focused workspace over a subset of the module data.
• Use reports when the team needs recurring visibility rather than one-off exports.
• Use JQL and reference namespaces when integrations or scripts need structured access to records.

Operating Notes From Source

• The backend app is src/hcm and the primary models define the durable record names used by JQL and reports.
• Most important work happens through model lifecycle actions, status fields, or controller endpoints rather than free-form notes.
• Where automation event constants exist, prefer those event names in workflows instead of inventing parallel naming.
• Where no explicit event class exists, build workflows around create, update, status change, and assignment changes for the module records.
• Permissions should follow the module role model first, then be narrowed by Base pages or object exposure only when needed.
• Imported data should be reconciled against module reports before it is trusted by downstream finance, payroll, inventory, or customer flows.
• Avoid duplicating module records in custom objects unless the custom object is only an extension or intake surface.
• Keep launchpad access, settings access, and API access aligned so users cannot automate records they cannot operate in the UI.

Related Pages

• Setup: /hcm-setup for configuration, prerequisites, and permissions.
• Working guide: /hcm-working for day-to-day flows.
• Data and automation: /hcm-data-automation for namespaces, workflow triggers, and reports.
• Reference: /reference/hcm.