Antylogic
DemoApp login

399 operational guides

Docs sections
DocsAttendance
Device

How to open an attendance correction for manual resolution

Open a pending staff shift correction from the Attendance corrections list, review the highlighted entry or exit time, then accept the requested value or adjust the time before closing the pending correction.

In this article

Attendance corrections are resolved from the same staff shift record that created the exception. Managers start from the pending corrections list, open the shift for manual review, and decide whether the requested clock-in or clock-out value should be kept or changed.

This guide is written for the GB demo context: Harbor Demo Group with Harbor Soho selected. Use a pending staff shift correction for a Harbor Soho employee such as Olivia Hart, Mason Reed, Noah Stone, or Ava Price when preparing captures.

Before you start

  • You are signed in with Harbor Soho selected in Harbor Demo Group.
  • Your user has `staff-shifts:view` and `staff-shifts:manage` for the selected location.
  • A pending `calendar_event` exists in Harbor Soho with `kind=staff_shift`, a `staff_id`, and `payload.start_status` or `payload.end_status` set to `correction_requested`.
  • The pending correction is inside the date range used by `attendance/corrections?pending_only=true`.

Instructions

  1. 1.

    Open pending corrections

    Open the Attendance corrections surface with `attendance/corrections?pending_only=true`. The list shows pending staff shift corrections for the selected location and prepares the table from the current date range.

  2. 2.

    Find the correction row

    Use the date range and employee filter to narrow the table. Check the employee, entry, exit, status, and hours columns before opening the correction.

  3. 3.

    Open manual review

    Open the pending row or use the row `Reject` action to inspect the shift manually. Do not use the table `Approve` action when the manager needs to review or adjust the time first, because that shortcut resolves the correction directly from the list.

  4. 4.

    Review the highlighted shift time

    The app opens the Edit attendance form for the `staff_shift` event. The pending entry or exit side is highlighted, date fields are locked, and only the time field for the pending side remains editable.

  5. 5.

    Accept or adjust the value

    Leave the pending time unchanged and choose `Accept correction` when the requested value is correct. Change only the editable pending time when the manager wants another value; the footer action changes to `Reject correction`.

  6. 6.

    Confirm the decision

    The footer opens a confirmation modal. Cancelling keeps the correction open on the form. Confirming saves the event and closes the pending entry or exit.

  7. 7.

    Check completion

    After the save, the app shows `The correction has been saved.` The resolved side is stored as `correction_made`; once the shift has no pending side left, it disappears from the pending-only list and the employee is notified.

  8. 8.

    Handle blocked states

    If the list is empty, widen the date range or prepare a pending correction in the documentation runtime. If the form cannot find the event, check that the event belongs to the selected location and is still a `staff_shift`. If access is denied, the operator lacks shift management permission.

Validations and limits

  • The corrections list and final save require `staff-shifts:manage`; loading the event detail requires `staff-shifts:view`.
  • The list request requires both `from` and `to`, and `to` must not be earlier than `from`.
  • Only `staff_shift` events with `payload.start_status` or `payload.end_status` set to `correction_requested` count as pending corrections.
  • The event must keep a non-empty `staff_id`; entry and exit values must be valid, and entry must be before exit when an exit exists.
  • The update cannot change the existing event kind, and staff shift payload statuses are limited to `normal`, `correction_requested`, and `correction_made`.
  • Do not describe `Reject correction` as a persisted rejected state. The implemented resolved state is `correction_made`.

Expected result

The manager closes the pending entry or exit on the staff shift event, the pending-only corrections list no longer shows the resolved row when no pending side remains, and Antylogic sends the staff member a correction decision notification.

Related articles