Time-off requests with calendar and approval updates

The time-off workflow began with a request tracked in Monday.com. In the recorded demonstration, a multi-day request was run manually. The scenario created a Google Calendar event, wrote the event link back to the request item and sent a Slack notification. The tracking record and calendar entry therefore referred to the same request.

A separate board review demonstrated adding another request and showed its event appearing in the calendar. The narrator had to adjust the user association during that demonstration. That detail matters because matching the request to a valid team member was part of the intake behavior, rather than something the downstream calendar steps could assume away.

The status-change test moved the request to denied. After the automation triggered, the calendar event’s wording reflected that decision. The narrator then moved the request to approved and showed the corresponding approved state. The workflow also included a notification to the time-off channel for the team member.

The automation’s role was coordination: a person made the approval or denial decision in the tracking system, and the connected calendar and communication followed that state. Calendar visibility did not replace the decision itself. The board review also left room to revise the desired handling of a denied request, so the final policy for every denied event is not established.

The first walkthrough deliberately separated request creation from later status updates. One trigger took roughly forty-five seconds; a later transition appeared to trigger immediately. The tests therefore demonstrated event creation and state changes while also revealing that the handoff was not consistently instantaneous.

The recording tested calendar creation and approval-state changes, but could not test the ordinary team-member form because a matching account was unavailable. The demonstrated result was a linked request and calendar entry that reflected a person’s decision.