Working in Attendance

Daily Operating Model

Attendance 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: Configure attendance for a location

1. Open Attendance Settings and confirm tenant-level rules.
2. Create shifts for the location or team.
3. Add exempt days and holidays that should not generate absence.
4. Register attendance devices and confirm connectivity metadata.
5. Map each device employee identifier to an HCM employee.
6. Run a small sync or import test.
7. Review raw logs and generated attendance records.
8. Adjust grace periods before the first live attendance cycle.

Flow 2: Review daily attendance

1. Open Attendance or Calendar for the target date.
2. Filter by department, location, shift, or employee.
3. Compare expected shifts with logs and computed records.
4. Investigate missing punches, late arrivals, early exits, and absences.
5. Correct source mappings or add approved exceptions where policy allows.
6. Notify managers about unresolved attendance issues.
7. Export or report the final daily position.
8. Lock or close the day according to the organisation process.

Flow 3: Process overtime

1. Employee or manager creates an overtime request.
2. Manager reviews hours, reason, shift context, and attendance evidence.
3. Approve, reject, or request changes.
4. Approved overtime is available for payroll or reporting handoff.
5. Use workflow notifications for approvals that are close to payroll cutoff.
6. Track overtime by team, project, or cost center if those dimensions are captured.
7. Audit repeated overtime patterns for scheduling changes.
8. Keep rejected requests with reasons for compliance history.

Flow 4: Maintain devices and mappings

1. Open Attendance Devices and check device status.
2. Review unmapped logs or employee IDs after imports.
3. Update DeviceEmployeeMapping when employees change devices or badge IDs.
4. Use device commands for operational actions supported by the controller.
5. Investigate devices with stale sync times or repeated failures.
6. Re-run imports only after duplicate handling is understood.
7. Keep device access restricted to administrators.
8. Use reports to confirm logs are flowing before each payroll period.

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/attendance for namespace and intent details.