The Awkward Problems in Calendar-Based Attendance Tracking

Calendar is editable; review needs a separate dated log

View full-size diagram

Conclusion first: Google Calendar is a scheduling tool, not an immutable attendance ledger. Edit history is incomplete, approval flows are absent, and exception handling does not exist, creating material legal exposure when used alone.

Calendar Events versus Audit Logs

Calendar events can be altered by any participant. The Calendar API only surfaces the last updated timestamp; it does not record who changed what or the prior state.

Recommended Data Model

Use an append-only ledger table with immutable rows:

• ledgerId, eventId, originalStart, originalEnd, actor, action, timestamp, approvalStatus, exceptionNote.

Apps Script Skeleton

Trigger onEventUpdate with LockService to serialize writes and append the before/after snapshot to a dedicated sheet. Respect the six-minute execution limit by batching.

Edit History Decision Table

Requirement	Calendar Native	Required Addition
Pre-change state	None	Append-only sheet
Actor identity	None	Session.getActiveUser()
Approval step	None	Separate approval sheet

Approval and Exception Checklist

• Create exception request form
• Add manager approval trigger
• Define 30-day retention policy
• Store deleted events separately

Failure Modes

• Concurrent edits cause lost updates
• Six-minute limit exceeded
• Calendar API quota breach

When Not to Use This Approach

For teams larger than ten people or where labor inspection is plausible, do not rely on Calendar alone. Review apps-script-automation-guide and lockservice-concurrency first.

Legal and HR Review Points

Cross-check personal data processing rules and Labor Standards Act Article 50. See when-to-leave-gas.

Final review criteria

The useful question is not how many features the automation has. It is whether the workflow can be understood, recovered, and safely rerun after something goes wrong.

• Raw input is separated from the human-facing working view.
• Each run records success, failure, processed count, and error message.
• Replaying the same input does not create duplicate results.
• Permission changes, quota errors, and external API failures are visible later.

For low-risk internal tasks, that may be enough. For customer replies, booking confirmation, inventory updates, payments, or legal records, the threshold is higher: compare Apps Script against a dedicated SaaS or a small server-backed system before relying on it.