Working in Payroll

Daily Operating Model

Payroll 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: Prepare a payroll period

1. Open Payroll Settings and confirm the active pay schedule.
2. Review employees assigned to the schedule and pay grade.
3. Confirm salary, earning, deduction, and bank details are complete.
4. Close attendance, timesheet, or manual time-entry input for the period.
5. Create or review expected pay run adjustments.
6. Notify managers about missing inputs before calculation.
7. Create the pay run for the target period.
8. Keep draft pay runs separate from approved payroll history.

Flow 2: Calculate and review a pay run

1. Open Pay Runs and select the draft run.
2. Calculate the pay run to generate employee lines.
3. Review gross pay, deductions, net pay, and exceptions.
4. Drill into PayRunEarning and PayRunDeduction detail for unusual lines.
5. Add approved PayRunAdjustment records where policy allows.
6. Recalculate after changes and compare totals.
7. Send the run for approval when finance and HR agree.
8. Do not post until approvals and bank/export checks are complete.

Flow 3: Approve and post payroll

1. Approver opens the pay run and reviews totals and exceptions.
2. Reject the run with comments when corrections are required.
3. Approve the run when all employee lines are correct.
4. Post the run to lock the payroll result and prepare downstream handoff.
5. Export payment or accounting data according to tenant process.
6. Notify employees or managers after posting if self-service is enabled.
7. Archive supporting reports for audit.
8. Void only through the controlled payroll action when reversal is required.

Flow 4: Maintain policies over time

1. Review pay schedules before every new period or fiscal change.
2. Update earning and deduction policies when benefits or rules change.
3. Assign employee or group policies to the intended population.
4. Test policy changes on a draft run before the live period.
5. Keep old policies inactive rather than deleting records used by historical runs.
6. Audit employees with missing policies or duplicate assignments.
7. Coordinate pay-grade changes with HCM effective dates.
8. Use reports to compare payroll cost by schedule, group, or 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/payroll for namespace and intent details.