Worked HR Scenarios

These examples show how related HR records should be followed through their own workflows. They are illustrative examples, not live tenant data, legal advice, statutory payroll calculations, or evidence that a provider accepted a transaction. Use your active company's policies, approved values, service, permissions and chart-of-account mappings. The scenarios deliberately name readbacks that must be checked instead of treating a button click as proof of completion.

Before using any scenario, read Capabilities and Access and HR Setup. If a screen is hidden, verify the selected company-service capability and user permission. If an API is unavailable, do not work around the route by directly inserting database rows.

Scenario 1: Requisition to employee record

Goal: hire for an approved seat without confusing the candidate, Party, employee, position, and user account.

1. In Workforce Setup, confirm that the job, grade and position are approved, effective for the intended hire date, and in the right service scope. If a new seat is needed, create and obtain approval for the workforce requisition using the configured approval path.
2. In Recruitment, create or select a candidate and create an application for the vacancy. Progress screening, interview, assessment and checks using the actual outcome and supporting evidence. Record rejection, waiver or exception reasons instead of advancing the application just to clear a queue.
3. Prepare an offer using an approved pay structure and currency. Review the salary frequency, start date, expiry and terms. Issue and record the candidate's decision through the offer actions.
4. When the candidate accepts, complete the employee handoff using the authorized Party/employee process. Confirm the Party carries the HR Employee role, the employee number was generated from its configured template, and the person is linked to the intended Party rather than a duplicate identity.
5. Assign the approved position, employment terms and reporting manager. If system access is required, link or create the system user and grant only the required role/permissions; recruitment acceptance alone must not be treated as access provisioning.
6. Review the employee detail and lifecycle history. Confirm employment state, position assignment and effective dates before setting up payroll, benefits, onboarding or self-service.

Expected evidence: approved requisition/position; candidate and application history; issued and accepted offer; employee/Party readback with HR Employee role; generated employee reference; effective employment and position; optional separately provisioned user link. Do not infer payroll enrollment or an active system login from the accepted offer.

Scenario 2: Leave, coverage, attendance and payroll input

Goal: understand four separate facts: requested time away, approved leave, planned coverage and observed attendance.

1. Confirm the employee is eligible for the leave type and inspect the current balance, pending requests and applicable period/calendar.
2. Submit a request for the dates and reason. The manager checks dates, entitlement, team coverage and handover; approve or reject the request with the appropriate permission. A rejected request should retain its decision and reason.
3. Review the roster and availability for the affected shifts. If approval creates a coverage conflict, inspect the exception, assign replacement coverage or record a justified resolution. Roster planning does not rewrite the leave request.
4. Capture actual attendance on the date the employee worked or was absent. If an absence should be converted to unpaid leave, use the supported conversion action and confirm the result against the leave and attendance records. Do not fabricate attendance to force a payroll deduction.
5. Review the leave ledger/reconciliation and the payroll input policy. Generate or preview payroll for the correct period, then inspect the run's source snapshot and lines to verify whether eligible paid leave, unpaid leave, absence or overtime was consumed.

Example: an employee requests two scheduled workdays off. The supervisor approves leave after arranging coverage. The roster records who is planned to cover those shifts; the leave record records authorized absence; attendance records actual work. Payroll should reflect only the approved source records allowed by the configured policy and period—not the roster alone.

Expected evidence: request decision; leave balance/ledger change; coverage assignment or resolved exception if required; attendance or absence record; payroll run source detail and reconciliation. A request marked Approved is not proof that payroll consumed it.

Scenario 3: Payroll run from enrollment through GL and payment

Goal: keep calculation, accrual, disbursement and statutory filing separate.

1. Confirm an open payroll period, approved employee enrollment, effective pay structure, payment details and payroll setup readiness. Resolve source exceptions before calculation.
2. Review input policy/version. Confirm which approved records are enabled and required: compensation, attendance, leave, overtime, benefits, loans or advances, arrears, one-off earnings and recovery deductions as configured. Payroll consumes source evidence; it is not the system of record for a loan balance or an inaccurate timesheet.
3. Preview the run, investigate inclusions/exclusions and compare gross pay, deductions and net pay to the supporting sources. Resolve errors at their owning workflow before regenerating or correcting the run.
4. Validate and approve using the configured roles. Approval and GL posting are distinct statuses. Inspect the payroll run detail and reconciliation before posting; if posting fails, repair its configuration and use the supported retry action rather than creating a duplicate journal.
5. Read back the GL batch: source payroll run, period, accounts/tags, debit and credit totals, and posted state must agree with the approved run.
6. Create a payment batch from the approved payroll results. Review the beneficiary, currency, amount and method. Cash and bank use separate settlement methods/accounts. Follow batch approval and bank execution if applicable; verify SETTLED/reconciliation evidence and the payable-clearing posting.
7. Prepare and export statutory filing/remittance data as supported. Record external authority acknowledgment only after receiving and reading back the actual provider/authority response.

Illustrative arithmetic only: if a worker has 2,000,000 in approved gross earnings and 250,000 in approved deductions, the arithmetic net is 1,750,000 before any other configured items. This is not a Uganda statutory calculation. Actual pay requires approved local rules and the payroll run's calculated snapshot.

Expected evidence: period; enrollment and effective structure; input-policy version and source lines; validated/approved run; posted GL batch; completed payment and payable clearance; filing or remittance receipt where applicable.

Scenario 4: Benefit life event, waiver, enrollment and provider invoice

Goal: trace an eligibility decision to coverage and reconciliation without confusing invoice approval with provider payment.

1. Approve the plan and define contribution amounts, currency and effective dates. Add explicit eligibility rules if default-open eligibility is not acceptable. A rule code is system-generated, not user-entered.
2. Record the employee's life event and required evidence. A reviewer records the outcome. Rejected, pending and approved events have different consequences; only an approved matching event inside a rule's window can satisfy the life-event condition.
3. If the employee declines coverage, record a dated waiver with a reason and decision. Check that an approved waiver does not cover the proposed enrollment date.
4. Run the eligibility check for the effective date. Review the decision and reason, then create/approve the enrollment. Check for duplicate/overlapping active or suspended enrollment before saving.
5. If the payroll policy includes benefit inputs, run payroll and inspect the consumed employee contribution and employer contribution lines. A plan amount does not itself prove a deduction.
6. Create the provider invoice with coverage dates and employee/enrollment lines. Reconcile billed totals against expected contribution values and, if linked, the payroll run's consumed source lines. Investigate all variances.
7. Approve only a matched invoice. Use the appropriate finance/payment process to settle the provider invoice and independently verify payment/GL; the HR invoice's Approved status is not settlement.
8. Generate the total-reward statement from the intended approved/posted payroll source. Review the source snapshot and version before distribution.

Expected evidence: plan/rule revisions; event and document reference; waiver decision where applicable; eligibility result; effective enrollment; payroll source lines; invoice reconciliation and approval; separate payment readback; versioned statement snapshot.

Scenario 5: Travel request, claim and two-stage accounting

Goal: recognize employee travel expense once and settle the payable later.

Assume only for this example that an approved policy pays 150,000 per eligible day, the trip lasts three inclusive days, and approved reimbursable receipts are 120,000. Any statutory/tax classification and policy amounts must come from the tenant's approved configuration.

1. Select the active service's approved, effective per-diem policy; check country, currency, dates, daily amount, meal reduction and lodging cap.
2. Create and submit the travel request with purpose, destination and dates. Obtain approval before incurring costs; approval authorizes the trip but does not create a payable or move money.
3. Create a claim linked to that request, classify each line's tax treatment, retain receipt evidence, and identify any real advance from the shared Loans module. Do not recreate the loan in HR.
4. Review policy limits and calculate the example per diem as 3 × 150,000 = 450,000. With 120,000 approved receipts, the illustrative approved claim is 570,000 before any reductions, rejected items, taxes, limits or advance reconciliation.
5. On approval, record the accrual once: Dr travel expense 570,000 / Cr employee travel payable 570,000 (illustrative). Confirm the posted accrual batch and claim reference.
6. For a subsequent bank settlement, complete the outbound payment through shared Payments, then link its settled same-service/same-currency transaction to the claim. Settlement clears the liability: Dr employee travel payable 570,000 / Cr CASH_BANK 570,000 (illustrative). A cash payment instead credits the separately mapped CASH_AT_HAND account.
7. Verify the payment status and settlement GL batch. Never debit expense again during settlement, and never credit the payable in both the accrual and settlement entries.

If there is an advance: if the approved claim is less than the advance, the employee must return the difference through the linked shared-loan repayment path and that repayment must be posted/reconciled before closing the claim. If the approved claim is greater than the advance, only the net amount due is paid.

Implementation warning: the backend router currently lacks the request and claim endpoint registrations used by the frontend, as described in Implementation Coverage. Treat this as a procedure/accounting example until route wiring is fixed and the UI flow has been proven end to end.

Scenario 6: Manager team queue and authority boundaries

Goal: act on a direct-report task without assuming row visibility grants approval rights.

1. Confirm the signed-in user is linked to the manager employee record and the active service. The My Team view must return only the manager's authorized reporting scope.
2. Open a leave, attendance, coverage or onboarding row. Read the source record's current status and employee/date context before acting.
3. Approve/reject leave or attendance only with the required action permission. For a rejection, provide the reason requested by the source workflow. For a coverage exception, use the supported acknowledge/resolve action with a resolution note; do not update the roster silently to make the exception disappear.
4. Reopen the source workflow and confirm its state and audit actor. Check the corresponding employee/payroll or roster outcome where relevant.

Expected evidence: manager-to-employee reporting relationship, restricted service scope, action permission, source-workflow decision and audit history. The manager capability alone does not authorize every action.

Scenario 7: Separation, clearance, settlement and access closure

Goal: exit an employee without treating a separation status change as proof that all downstream liabilities and access have been resolved.

1. Initiate a separation with its reason, notice date and expected last working day. Obtain the required review and confirm the approved effective date.
2. Generate the employee's clearance items from configured definitions. Assign accountable owners, record return/waiver evidence and resolve exceptions. Include company assets, access credentials, documents, knowledge transfer, and any outstanding loan/advance or departmental obligation that applies.
3. Confirm final-period attendance, leave, payroll inputs, benefits and deductions. Use the authoritative final-settlement calculation workflow and inspect each component rather than typing an unexplained net figure.
4. Leave manual amount overrides empty when requesting the source calculation. Review each component against the approved payroll enrollment, leave ledger, linked Loans balances and eligible adjustments. The current routine rejects a negative net and the form does not expose the required override reason, so neither a recovery nor a manual correction should be forced through this settlement form.
5. Obtain independent settlement approval. If paying, select Cash or Bank and verify that Cash resolves to CASH_AT_HAND and Bank to CASH_BANK. Read back the shared payment transaction and posted GL batch. The checked-in payment rule debits the payroll gross-expense tag and credits cash/bank; the settlement creation path does not record a separate payable accrual. Finance must confirm that this is the approved accounting treatment before the workflow is represented as a two-stage payable process.
6. Do not treat “approved” as “paid” or SETTLED as the final employment lifecycle state. Complete the authorized lifecycle transition, verify the employee timeline, and separately confirm account access disposition.
7. Complete separation only after required clearance, settlement and employment-status steps are resolved. Review the lifecycle timeline, access disposition, final payroll and audit trail.

Expected evidence: approved separation dates; per-item clearance state and owner; final settlement calculation detail and independent approval; actual payment transaction and GL batch (or a separately approved recovery workflow); Finance confirmation of the settlement posting model; access disposition; and final employee lifecycle status/timeline.

Scenario 8: Performance review to a governed compensation change

Goal: keep assessment, development actions and pay changes connected but separate.

1. Open an active performance cycle, confirm review participants, period and target definitions, and assign the employee/reviewer through the supported workflow.
2. Record target progress with dates and evidence. Complete review comments and ratings according to the cycle. Avoid using a rating as a substitute for a documented decision.
3. Assign training or update skills where justified, with completion evidence recorded only after the employee completes the programme.
4. If the outcome supports promotion or increased pay, create a separate effective-dated promotion/transfer or salary revision, submit it for the required approval, and verify the resulting position/payroll applicability.
5. Confirm the next payroll run consumes the approved compensation change from the correct effective date. Do not edit the shared salary structure to change one employee's historical pay.

Expected evidence: cycle and reviewer; target results/evidence; review decision; training completion; separate approved employee-change record; and payroll period/source snapshot showing when the revised terms take effect.

Scenario 9: Roster gap, leave conflict and exception resolution

Goal: make a staffing gap visible and resolved rather than hiding it in a roster edit.

1. Confirm the approved shift, roster period and required coverage rule. Assign employees to the intended dates and shifts and publish the roster.
2. Enter or review employee availability and approved leave for the same period. Do not treat a roster assignment as overriding approved leave.
3. Scan coverage exceptions. For each gap, verify date, shift, skill/headcount requirement, availability and leave conflict. The scan output is a finding, not a resolved exception.
4. Acknowledge an exception when an owner accepts it. Resolve only after a roster/availability adjustment or an authorized waiver, with a clear note.
5. Re-run or refresh the exception list. Confirm resolved items are no longer open and the roster still meets its coverage rule.
6. Check the manager's My Team view to confirm the manager sees only their service-scoped direct reports and the same underlying roster/exception records.

Expected evidence: published roster; availability rows; exception scan result; owner and resolution note or approved waiver; refreshed exception state. Do not claim coverage is resolved simply because an exception was acknowledged.

Scenario 10: Loan installment and prior arrears in a payroll run

Goal: prove payroll reads authoritative shared-Loans values without creating a competing HR loan balance.

1. Verify the employee is linked to the correct Party and shared Loans account, and that the loan is approved, individual-held, service-scoped and in an eligible account state.
2. Review the due installment in Loans. Confirm due date falls in the payroll period and that remaining installment amount reflects prior principal, interest, fee, penalty, tax and rounding payments.
3. If the account is in arrears, have Loans confirm the approved overdue balance/state. Do not manually convert a missed instalment into an HR adjustment and do not infer arrears from an old payroll period alone.
4. Check the Payroll Input Policy separately for Loans and salary advances and Loan arrears. An installment due in-period and an overdue account balance are different source categories and can both be configured; review for policy overlap/double recovery before calculating.
5. Preview payroll and inspect the source snapshot's schedule/account references and captured amounts. Compare these with current Loans data and the employee's other deductions and net-pay controls.
6. Approve and post payroll under normal controls. Then verify the loan repayment is posted/reconciled in Loans and that the account balance and arrears state changed as expected. Payroll deduction by itself is not proof that the loan account was credited.

Expected evidence: loan account and schedule; overdue balance if any; payroll policy version; source snapshot with distinct installment/arrears facts; approved run and GL; Loans repayment posting; updated loan readback.

Scenario 11: Leave balance discrepancy and ledger reconciliation

Goal: correct a leave balance from its ledger rather than overwriting a displayed total.

1. Select the employee, leave type and fiscal year. Compare the displayed balance with its ledger and leave requests; identify the source of the difference (missing entitlement, accrual, carry-over, adjustment, approved leave taken/reversed, or expiry).
2. Confirm the leave type's accrual/carryover policy and fiscal-year boundary. Check whether a scheduled approved leave request is included in the forecast but not yet deducted from the current ledger.
3. Use ledger reconciliation to identify a cache-versus-ledger mismatch. Reconcile after confirming the ledger is complete; reconciliation should restore consistency from authoritative movements, not invent an entitlement.
4. If a genuine balance correction is needed, create an approved adjustment with effective date, reason and evidence. Do not edit the stored balance or alter a leave request to represent an entitlement correction.
5. Recheck ledger total, current balance and forecast. Confirm future accrual, scheduled leave and projected year-end values make sense for the chosen fiscal year.

Expected evidence: selected fiscal year/type; source leave requests and ledger movements; reconciliation result; approved adjustment if needed; final balance and forecast readback.

Scenario 12: Benefit invoice variance to payroll source lines

Goal: isolate a provider invoice difference without treating plan configuration or invoice approval as payment.

1. Choose a provider invoice and plan and verify its exact coverage dates, currency, invoice reference and employee/enrollment lines.
2. Reconcile billed employee contribution and billed employer contribution separately to approved active enrollment and the effective plan values.
3. Link the matching payroll run only if the run is approved/posted and its period exactly matches the invoice coverage dates. Inspect consumed benefit source lines, not an unapproved enrollment or an unsnapshotted plan amount.
4. If the invoice is Exception, determine whether the source is a stale enrollment, incorrect plan amount/date, missing employee line, incorrect invoice amount, or payroll-period mismatch. Correct the source record or return/reject the invoice through the available workflow; retain the variance explanation.
5. Approve only after the reconciliation outcome is acceptable. Then use the appropriate finance/payment workflow and read back provider payment and GL settlement independently.

Expected evidence: provider invoice; coverage interval; approved enrollments; plan values; payroll source snapshot and lines if linked; matched reconciliation; approval; separate provider payment and accounting proof.

Scenario checklist

For any HR example, check each boundary independently:

• correct company-service and effective date;
• capability active and user permission present;
• employee/Party identity and reporting scope correct;
• setup entity approved and selectable by readable code/name;
• source record submitted and decision auditable;
• downstream record created by its owning workflow;
• GL, payment, delivery or external acknowledgment read back when money/data leaves HR;
• no duplicate employee, enrollment, journal, payment or source consumption;
• final state and history consistent across employee detail and reports.

Related guides

• Capabilities and Access
• HR Setup
• Employees
• Leave and Attendance
• Payroll
• Benefits and Total Rewards
• Travel and Expenses
• Lifecycle and Manager Workspaces
• Separation