Blog Body
Start with the exception, before any consequence
An attendance report may show missing time even though an employee had an approved assignment or a shift changed without the schedule being updated. Good review asks why the difference exists and where it came from before any consequence follows. The aim is a record explaining what happened, who reviewed it and what was corrected, rather than more alerts or treating every difference as misconduct. This proposed operating model should be adapted by HR to the entity, employment context and applicable policies.
Define the exception before automating it
An exception is a difference requiring review between a recorded event and an approved schedule, assignment or policy. Do not treat every difference as absence or every correction request as accepted. Define categories, limits, time sources and remote work, assignment and shift-change cases under applicable policy and requirements.
Design a clear decision path
Define reviewer, approver, consultation, delegation, escalation and conflict-of-interest cases. The employee should see request status and a reason for rejection or return. Link the decision to the policy and schedule version effective at the event time, not only the current configuration.
Collect the minimum suitable evidence
Request evidence appropriate to the exception type and explain purpose, retention and access. An assignment approval or system record may be enough; excessive health or personal data is not. Where biometric attributes are used, apply relevant privacy, security and entity-specific obligations.
Separate record correction from downstream effect
Correcting a timestamp or day type may still require a separate authorized update to payroll, balance or reporting. Prevent undocumented direct changes and retain original and amended values, reason, actor, time and supporting evidence.
Monitor the process without excessive surveillance
Measures such as review time, recurring exception types and requests returned for missing evidence can improve the process, but they do not prove individual misconduct. Review data quality, rule bias and appeal access, and restrict access to legitimate work needs.
An exception card that can be reviewed
Use one reference connecting the event, request and decision. Record exception type, event date, effective schedule, original value, requested correction, evidence reference, review owner, status, decision and reason. Add a separate downstream task where needed. Do not expose personal attachments in a general dashboard; a restricted reference is sufficient for authorized reviewers. Recording actor, time, outcome and reason and protecting logs is consistent with OWASP technical guidance [2]. That is a security reference, not a Saudi attendance regulation.
| Field | What to record |
| Event and reference | Exception type, event date, time source and effective schedule |
| Request and evidence | Requested correction and access-controlled evidence reference |
| Review and decision | Reviewer, delegate, status, reason and timestamp |
| Correction and effect | Before and after values, change owner and report or balance check |
Illustrative example: a field assignment absent from the schedule
In a fictional case, an exception is raised because no office check-in exists. The reviewer checks the assignment reference, date and scope, then the schedule used when the alert was created. If the evidence supports the case under policy, record the decision and update the authorized record. The responsible owner then checks any reporting or balance impact. If evidence is incomplete, return the request with a specific explanation rather than accepting it automatically. This example sets no grace period, deduction or penalty and represents neither a client case nor a legal rule.
Check applicability before configuring rules
HRSD published an announcement on updated Labor Law implementing regulations in February 2025 [3]. That does not establish that Labor Law rules apply to every government entity or employment category. A specialist should identify the governing law, regulation and policy before configuring workflow or financial consequences. For employee data, review purpose, lawful basis, access, retention and individual rights. SDAIA’s minimum data guidance links collection to actual need [4]. This example does not authorize biometric collection or automated decisions affecting employees.
Translate the model into configuration requirements
RMG’s Rasd page describes attendance, requests, reporting and work schedule functions [1]. The exception card, separation of review from downstream effects and permissions proposed here are requirements whose implementation should be checked during solution analysis, rather than a claim that every function is available out of the box. Start with RMG by documenting exception categories, schedule and assignment sources, roles and reporting needs. Test a complete journey, a returned request and a source outage before expanding.
