Download, Upload, and Post Zoom Recordings

Problem

Zoom recordings needed to be downloaded, stored in the right Google Drive locations, and shared with the right operational destinations after meetings ended. The source inventory confirms that the workflow handled all-meeting recording events, routed them by meeting metadata, and posted recording links to Slack and/or ClickUp where configured.

The exact route names and which routes remained active after the later Apps Script router are not confirmed in the public-safe inventory, so this case study describes the routing categories in generalized terms.

Objectives

• Watch completed Zoom recording events automatically
• Download eligible recording files from the Zoom payload
• Filter out files below a configured minimum size
• Route recordings by meeting conditions, topic, host metadata, or configured rules
• Upload recordings to Google Drive destinations
• Post Drive links to Slack and/or ClickUp for configured routes
• Keep private route names, folder IDs, task IDs, and channel identifiers out of public content

Solution

This Make scenario handled completed Zoom recording events, iterated through recording files, downloaded eligible cloud recordings, applied route conditions, uploaded recordings to Google Drive, and posted links to configured Slack and ClickUp destinations.

The inventory also notes this was the original Make scenario before many routes were later moved to the Apps Script Zoom Recording Router to reduce Make data usage.

Architecture

The confirmed architecture is a Make-based integration flow: Zoom provides a completed recording webhook payload, Make iterates through recording files, route logic selects the destination, Google Drive stores the file, and Slack or ClickUp receives the public-safe recording link.

Workflow

1. Zoom sends a completed recording event to the Make scenario.
2. Make iterates over the recording files in the payload.
3. The scenario filters for view recordings and excludes files below the configured minimum size.
4. Eligible recordings are downloaded from Zoom.
5. Meeting metadata and route conditions determine the matching delivery path.
6. The recording is uploaded to the configured Google Drive destination.
7. The resulting Drive link is posted to Slack and/or ClickUp when the route requires it.

Tools Used

• Make - orchestration, iteration, route filters, and service-to-service delivery
• Zoom - completed recording webhook payloads and recording downloads
• Google Drive - destination storage for uploaded recordings
• Slack - operational notifications for configured routes
• ClickUp - task comments for configured routes

Technical Decisions

Route conditions in Make: The source confirms route logic based on meeting conditions, meeting metadata, host metadata, and fallback or catch-all behavior. Exact route names are not public-safe or not confirmed, so the portfolio should represent them as generalized route categories.

Minimum file-size filtering: The source confirms a minimum size threshold before delivery. The exact threshold is not included in the public-safe inventory.

Evolution to Apps Script: The inventory confirms that many routes were later moved to the Apps Script Zoom Recording Router to reduce Make data usage.

Challenges Solved

• Multi-file recording payloads: The workflow iterated over recording files from each completed Zoom event.
• Route-specific delivery: Meeting metadata and configured route conditions determined where each recording should land.
• Public-safe sharing: The portfolio description must avoid exposing route names, Slack channel identifiers, ClickUp task IDs, or Drive folder IDs.
• System evolution: The Make scenario became part of a larger automation history once selected routes moved to Apps Script.

Results

The confirmed outputs were Google Drive recording files, Slack messages, and ClickUp task comments for configured routes.

Quantified outcomes such as time saved, delivery volume, error rate, or data-usage reduction are not confirmed in the provided inventory and should remain generalized until verified.

Future Improvements

• Generalized: clarify which routes remained active after the Apps Script router took over selected meeting types.
• Generalized: decide whether catch-all behavior should be shown publicly or kept as an implementation detail.
• Generalized: document which meeting route names are safe to use in public diagrams.
• Generalized: compare the Make scenario with the later Apps Script router as an evolution story.

Lessons Learned

Generalized: recording workflows should be designed around route clarity, retry visibility, and public-safe naming. Even when the automation works, the portfolio version should not expose the real internal destination map.

The confirmed lesson from the inventory is architectural: this scenario eventually pushed some routing responsibility toward Apps Script because Make data usage became a concern.

If I Rebuilt This Today

Generalized: I would first confirm which routes should still live in Make and which should belong in the Apps Script router, then document the boundary between the two systems before changing the automation.

I would also keep the public case study focused on workflow shape and reliability concerns, not private meeting names or destination identifiers.

Engineering Notes

• Confirmed trigger: Zoom completed recording webhook.
• Confirmed services: Make, Zoom, Google Drive, Slack, ClickUp.
• Confirmed outputs: Drive files, Slack messages, ClickUp comments.
• Unconfirmed: public-safe route names, active route ownership after the Apps Script migration, catch-all visibility, and whether host-based routing should appear in the final portfolio animation.