Architecture review - Attendance anomaly detection

Help Orchestrator
, ,
1

We’re replacing a manual attendance reconciliation process with RPA. Today we have clock-in/out logs (Time & Attendance system in an Oracle TMS database) and approved leave/travel records (HCM system, Core HR only) which capture employee leave records.

Our issue: We cannot know if an employee came in late, left early, skipped a lunch punch, or didn’t show up at all. No system tells us that — no notification, no trigger, nothing. The only checkpoint is payroll calculation, by which point it’s too late to catch it in real time, and manual cross-checking is prone to human error.

Proposed solution: We’re planning to use UiPath for this.
An unattended bot will run on schedule (daily, plus a monthly full-cycle pass) to pull TMS and HCM data, reconcile the two, and flag anomalies (late arrival, early departure, missed punch, unauthorized absence, undertime) against our internal attendance rules matrix (grace periods, allowed monthly undertime hours, etc. — role-based).

Anomalies get pushed into a third system accessible to employees, where each employee can view their own flagged anomaly and take action (e.g., submit justification, link it to an approved leave/travel request, or acknowledge undertime/overtime).

The employee’s manager then reviews and approves or rejects that action; if the manager doesn’t respond within a set SLA, it auto-escalates to HR. HR is notified either to proceed with a payroll deduction (per our penalty structure) or to close the anomaly with no action, depending on the outcome.

The intent is to close the loop that doesn’t exist today: detect anomalies same-day (or same-cycle) instead of at payroll time, give employees/managers a structured way to resolve them, and only involve HR for final deduction decisions — cutting out manual log-checking entirely.

Scale: 800+ employees, daily or each 3 days + monthly processing cycles, two source systems (TMS, HCM) plus one new resolution/workflow layer.

What we’d like the community’s honest view on:

  1. Reliability — is a daily-reconciliation-bot + third-party workflow system a dependable long-term pattern at this scale, or is there a structural weak point we’re not seeing (e.g., data drift between TMS/HCM, timing of the two source pulls, bot failure mid-cycle)?

  2. Possible issues — what typically goes wrong in attendance-anomaly RPA builds like this once they hit production? Race conditions between employee action and escalation timers, duplicate anomaly pushes, HCM write conflicts, anything else you’ve hit?

  3. Considerations before we build — A recommendation on right fit for the third system (Oracle Apex is on our list) Any guidance on audit trail / traceability requirements we should bake in from day one given this affects payroll?

Kindly share any of your thoughts on this.

2

@Ali3494

This approach is workable, but I would not treat it as just an RPA project. The bot can handle the daily reconciliation, but the real success depends on having a strong exception-management workflow, proper audit trail, and clear ownership of each anomaly.

At your scale, 800+ employees is not a problem for UiPath if the process is designed properly. The bigger risk is not volume, but data timing and consistency. For example, TMS punches may be available immediately, while HCM leave or travel approvals may be entered later or approved after the fact. If the bot flags someone absent before their leave request is approved, you may get false anomalies. So you need a clear rule for when an anomaly becomes “final” versus “pending validation.” I would suggest having statuses like New, Pending Employee Action, Pending Manager Approval, Escalated to HR, Closed - Approved, Closed - Deduction, and Closed - No Action.

The most common production issues will likely be duplicate anomalies, late-arriving leave records, missed punches corrected after the bot already ran, manager SLA timers triggering too early, and bot failures halfway through a cycle. To avoid this, each anomaly should have a unique key, maybe based on employee ID, attendance date, anomaly type, and shift. That way, if the bot runs again, it updates the existing anomaly instead of creating a duplicate. The bot should also be restartable, meaning if it fails mid-run, it can continue safely without corrupting the workflow data.

For the third system, Oracle APEX can be a good fit if your organization is already using Oracle and you need a lightweight workflow portal with database-backed auditability. It would allow employees, managers, and HR to interact with the same anomaly records without depending only on UiPath queues or spreadsheets. The key is to make the workflow system the source of truth for anomaly status, not the bot. The bot should detect, create, update, and notify, but the business process should live in the workflow layer.

Since this impacts payroll, audit trail is very important from day one. You should capture who created the anomaly, when it was created, what data was used from TMS and HCM, what rule was applied, who acted on it, who approved or rejected it, timestamps for each action, comments, attachments, and final payroll decision. Also keep the original source values used during reconciliation, because later the data in TMS or HCM may change and you will still need to explain why a decision was made at that time.

Overall, the idea is solid, but I would design it as a reconciliation and case-management solution, not just a scheduled bot. UiPath is fine for the automation layer, but the workflow system, exception handling, audit trail, duplicate prevention, and retry logic will decide whether it works reliably in production.