AI Ops BuilderPortfolio
← All projects

Workflow Preview

Zoom Recording Router

Routes Zoom recording webhooks through Apps Script validation, category-based routing, delivery, logging, and retry flows.

01Trigger

Zoom Webhook

02Orchestrator

Apps Script Web App

03Action

Validation + Deduplication

04Decision

Route Matcher

05Decision

Meeting ID / Category / Host-Based Rules

06Output

Post to Slack and/or ClickUp

07Output

Execution Log

08Support

Retry Failed Webhooks

Starts: Receive Zoom recording event

Ends: Retry failed webhooks

Case Study

Zoom Recording Router

Apps Script webhook router that validates Zoom recording events, deduplicates processing, routes by public-safe meeting categories, stores recordings, posts updates, logs runs, and supports retries.

Published Timeline: 1 weekRole: BuilderContext: Internal operations team
Workflow AutomationIntegrationsRoutingPipeline
Apps ScriptZoomGoogle DriveGoogle SheetsSlackClickUp

Problem

Zoom recording webhooks needed to be processed reliably after meetings ended. The confirmed source workflow routes completed recording events into public-safe meeting categories, stores the recordings, posts links to Slack and/or ClickUp when applicable, logs execution outcomes, deduplicates processing, and supports retries for failed webhook runs.

The underlying route configuration includes private meeting rules and destination IDs, so the public case study uses generalized categories instead of real meeting names, Slack channels, ClickUp task IDs, or Drive folder IDs.

Objectives

  • Receive Zoom recording.completed webhook events through an Apps Script web app
  • Validate incoming events and prevent duplicate processing
  • Match recordings to public-safe route categories
  • Download matched recordings and upload them to Google Drive
  • Post Drive links to Slack and/or ClickUp when configured
  • Log execution outcomes in Google Sheets
  • Preserve retry paths for failed webhook processing
  • Keep private route names, IDs, destinations, tokens, and webhook details out of public content

Solution

I built an Apps Script web app that receives completed Zoom recording events, validates and deduplicates the payload, applies route-matching logic, downloads the recording, uploads it to Google Drive, and posts the resulting link to Slack and/or ClickUp where applicable.

The workflow also logs executions and supports retry handling for failed webhook runs. The inventory mentions a Cloudflare Worker relay in front of the Apps Script web app, but whether that relay should appear in public portfolio diagrams is not confirmed.

Architecture

The confirmed architecture is Zoom webhook to Apps Script web app to validation and deduplication, then route matching, recording download, Google Drive upload, Slack/ClickUp delivery, Google Sheets logging, and retry support.

Zoom Recording Router
  1. 1
    Zoom webhookTrigger

    A completed Zoom recording event enters the router.

  2. 2
    Apps Script web appAction

    The web app receives the relayed webhook payload.

  3. 3
    Validation + deduplicationAction

    The event is checked and duplicate processing is avoided.

  4. 4
    Route matcherDecision

    Meeting metadata is mapped to public-safe route categories.

  5. 5
    Upload to Google DriveAction

    The matched recording is stored without exposing folder IDs.

  6. 6
    Post to Slack and/or ClickUpOutput

    Configured routes receive the Drive link.

  7. 7
    Execution log and retry supportOutput

    Run outcomes are logged and failures can be retried.

Workflow

  1. Zoom sends a recording.completed webhook event.
  2. The webhook is relayed to an Apps Script web app.
  3. Apps Script validates the payload and deduplicates processing.
  4. Eligible events enter the route matcher.
  5. Meeting ID, category, and host-based rules are applied where configured.
  6. A catch-all route handles unmatched or generalized routing behavior.
  7. Matched recordings are downloaded and uploaded to Google Drive.
  8. Drive links are posted to Slack and/or ClickUp when applicable.
  9. Execution outcomes are logged in Google Sheets.
  10. Failed webhook runs can be retried through the router.

Tools Used

  • Apps Script - webhook handling, validation, route matching, delivery orchestration, logging, and retry support
  • Zoom - completed recording webhook payloads and recording downloads
  • Google Drive - storage destination for recording files
  • Google Sheets - execution logs and failed webhook records
  • Slack - recording link notifications for configured routes
  • ClickUp - task comments for configured routes

Technical Decisions

Apps Script router: The normalized inventory identifies the latest router as an Apps Script web app, not the older Make recording workflow.

Validation and deduplication: The workflow validates incoming events and prevents duplicate processing before route matching.

Public-safe route categories: The route categories are generalized as internal team meetings, leadership meetings, onboarding, client meetings, internal client strategy, operations meetings, daily or weekly huddles, and catch-all routing.

Retry support: The inventory confirms retry handling for failed webhooks. Whether retry behavior should appear as a primary workflow branch or a supporting reliability layer is not confirmed.

Challenges Solved

  • Webhook reliability: The workflow validates events, deduplicates processing, logs outcomes, and supports failed webhook retries.
  • Route privacy: Public diagrams must avoid internal meeting names, channel identifiers, task IDs, folder IDs, and webhook details.
  • Multi-destination delivery: Configured routes can post recording links to Slack and/or ClickUp after Drive upload.
  • Fallback handling: The router includes catch-all behavior for unmatched or generalized route cases.

Results

The confirmed outputs are Google Drive recording files, Slack messages, ClickUp task comments, Google Sheets execution logs, failed webhook records, and retry or error notifications.

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

Future Improvements

  • Generalized: decide whether the Cloudflare Worker relay should be visible in public diagrams or treated as an implementation detail.
  • Generalized: decide whether retry behavior should be a primary branch or a supporting reliability layer.
  • Generalized: confirm how host-based routing should be represented publicly.
  • Generalized: keep route labels public-safe unless each route name is approved.

Lessons Learned

Generalized: webhook routers need reliability features around the happy path, not just delivery steps. Validation, deduplication, execution logs, fallback routes, and retry support are part of the system's core value.

The public version of this case study should focus on the routing and reliability pattern rather than exposing the private route table.

If I Rebuilt This Today

Generalized: I would first document the public-safe route taxonomy and decide how much of the relay and retry infrastructure belongs in the portfolio diagram.

I would also keep a clear separation between confirmed workflow behavior and private configuration that should not appear in screenshots or examples.

Engineering Notes

  • Confirmed trigger: Zoom recording.completed webhook event.
  • Confirmed services: Zoom, Apps Script, Google Drive, Google Sheets, Slack, ClickUp, and a Cloudflare Worker relay.
  • Confirmed public-safe categories: Internal Team Meetings, Leadership Meetings, Team Player Onboarding, Client Meetings, Internal Client Strategy, Operations Meetings, Daily / Weekly Huddles, Catch-All Route.
  • Unconfirmed: whether to show the Cloudflare Worker in diagrams, whether retry is primary or supporting flow, and how to represent host-based routing.