Tracking staff attendance in Google Calendar: where records break

Calendar is editable; review needs a separate dated log

View full-size diagram

A manager checks who worked which shift by looking at a shared Google Calendar. Then someone drags Tuesday’s event to Wednesday, and there’s no reliable way to show what it said before.

The answer: Google Calendar is a scheduling tool, not an attendance record. Its edit history is incomplete and it has no approval or exception flow, so if attendance feeds pay or labor records, keep an append-only log in Sheets or a database next to it. Used alone, the calendar leaves real legal exposure. For a setup like that, see work automation on Google Sheets.

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.