Working in HCM

Daily Operating Model

HCM works best when teams treat the module record as the source of truth and use tasks, tickets, workflows, and reports as supporting surfaces. The flows below are the common day-to-day paths to validate during setup and train users on after go-live.

Flow 1: Onboard an employee

1. Open Employees and create the employee record with personal, contact, location, and employment details.
2. Attach the Antly user account when the employee needs self-service access.
3. Assign department, unit, position, job role, pay grade, and manager.
4. Complete dynamic employee sections such as emergency contacts or compliance questions.
5. Add salary and bank details only for roles allowed to manage compensation.
6. Seed leave balances or confirm accrual policies will create them.
7. Use tasks or workflows to assign onboarding actions to IT, facilities, and the manager.
8. Validate the employee can open Home or My Profile and see the correct self-service screens.

Flow 2: Run leave operations

1. Confirm leave types, policies, and balances are configured.
2. Employee opens Leave and creates a leave request for the required dates.
3. Manager or HR reviews the request from the leave queue or task notification.
4. Approve, reject, or ask for changes according to the policy.
5. Check that balances and calendars reflect the final decision.
6. Use reports to review upcoming leave, usage, and balance exceptions.
7. Trigger notifications or tasks for coverage handoff when leave is approved.
8. Audit unusual balance changes before payroll or month-end close.

Flow 3: Complete a performance cycle

1. Create or review the performance review template and reviewer assignments.
2. Open Performance and start the review cycle for the target employees.
3. Employees and reviewers submit goal progress, question responses, and feedback.
4. Managers calibrate ratings, request clarifications, or reopen assignments if required.
5. Complete and share the review when all required inputs are submitted.
6. Convert agreed actions into goals, training plans, or tasks.
7. Use reports to compare completion, ratings, and overdue review assignments.
8. Archive the cycle only after HR confirms downstream compensation or development actions.

Flow 4: Operate training and exit management

1. Publish training courses and group them into training plans.
2. Assign plans to employees, job roles, departments, or onboarding cohorts.
3. Track enrollment progress, quiz attempts, and completion evidence.
4. When an employee is leaving, create an exit process and choose the correct checklist template.
5. Assign offboarding checklist items to HR, IT, finance, and the line manager.
6. Collect final documents, asset returns, and payroll handoff tasks.
7. Complete the exit process after all checklist items and approvals are closed.
8. Review training and exit dashboards for gaps that need manager follow-up.

Day-To-Day Controls

• Start from the launchpad route, then use filters and saved views to focus on records needing action.
• Use status fields and lifecycle actions instead of free-text notes for important state changes.
• Attach documents, comments, or related records when a decision needs evidence.
• Create tasks when work leaves the current owner or needs a due date.
• Create tickets when the work is customer-facing or belongs in a support/service queue.
• Use workflows for predictable notifications, approvals, escalations, and cross-module updates.
• Use reports for recurring team reviews rather than exporting ad hoc lists every time.
• Keep permissions tight enough that users see the records they need but not sensitive configuration.
• Review rejected, cancelled, failed, or overdue records every week.
• Keep integrations aligned with the same lifecycle users follow in the UI.

Exception Handling

• If a record is stuck, check owner, status, required fields, approvals, and linked records before editing downstream data.
• If a workflow did not run, confirm the event name, trigger filter, record permissions, and service-user access.
• If reports look wrong, inspect whether the source record is draft, cancelled, archived, or missing a required dimension.
• If an integration created bad data, fix the source mapping and then repair the affected records through supported actions.
• If users cannot see a route, review launchpad access, module roles, page permissions, and tenant feature flags.
• If a public or embedded route exposes too much, disable exposure first and then correct permissions or filters.
• If two modules disagree, choose the module that owns the lifecycle as the source of truth and update the other from it.
• If a record supports audit, void, archive, or cancel it instead of deleting it whenever possible.

Reporting Rhythm

• Daily: review new, overdue, failed, rejected, and pending-approval records.
• Weekly: review owner workload, aging, status changes, and recurring exceptions.
• Monthly: review configuration, permissions, integration failures, and report definitions.
• Quarterly: review whether custom pages, workflows, and API access still match real operating practice.
• After major process changes: rerun one end-to-end flow with a pilot record before enabling it broadly.

Cross-Module Handoffs

• To Base objects: pass stable identifiers, owner, status, dates, and any dimensions required for reports.
• To tasks: include a precise action, due date, source record link, and escalation owner.
• To tickets: include requester, priority, support context, and the module record link.
• To workflows: prefer explicit create, update, approval, and status-change triggers.
• To reports: keep dimensions consistent across records so dashboards can group accurately.
• To integrations: use /reference/hcm for namespace and intent details.