How RecordFlow Handles Your Data

Before you approve a third-party app for your whole Zoom account, "trust us" isn't an answer a security reviewer accepts. You want specifics: does it keep a copy of the recording? Can it see people who haven't opted in? What actually happens the day you remove it? A privacy policy page can say anything — what matters is whether the claims hold up against the code that runs in production.

So this post makes exactly the claims our marketing makes about the admin-managed app, and for each one, says what we checked to confirm it's true rather than just asserting it.

What's actually happening

RecordFlow's admin-managed app asks a Zoom account admin for five read-only permissions at install: seeing who's on the account, reading the admin's own profile, and three for reading recordings (listing them, listing the files inside each, and reading those files — the transcript rides along as one of those files). No write scope, no delete scope. What we do with that access — what we store versus discard, who controls it, what disappears on removal — is the part worth verifying rather than trusting.

What we never store: recording bytes

A recording's video, audio, transcript, and chat files never touch a database or a disk we control. RecordFlow streams each file from Zoom's API in 10 MB chunks, directly into an upload to your Google Drive folder — a chunk sits in Worker memory for the moment it's mid-transfer and is gone once it's written to Drive. There's no object-storage bucket or cache layer holding recording content anywhere in RecordFlow's infrastructure; what little caching the sync pipeline does is limited to Drive folder IDs, so it doesn't recreate the same folder twice mid-run — never file content. If you deleted RecordFlow's entire database tomorrow, no recording would be in it, because none ever was. That's also what keeps the service secure by construction: there's no recording archive on our side for an attacker to go after in the first place.

What we minimize: the account-wide roster scope

To show an admin who's on their Zoom account, RecordFlow requests a single scope — user:read:list_users:admin. Zoom's response for that call carries more fields than we need; RecordFlow keeps exactly four per person — Zoom user ID, name, email, and active/inactive status — and discards the rest before anything is written to our database. Those four fields are the entirety of what we retain about a member before they're enrolled. The scope is never used to read anyone's recordings; recording access runs through entirely separate scopes, and only for members an admin has enrolled. Practically: installing the app and seeing your roster doesn't put a single byte of anyone's recording content in front of RecordFlow. That only starts once an admin turns a specific member on.

Who controls enrollment — and it isn't the member

Here's a claim worth being precise about, because it's easy to overstate: enrollment is admin-controlled, not a self-service member toggle. Only a Zoom account admin can flip a member's switch on the admin dashboard — there's no member-facing "opt in" button, by design; the admin is the one accountable for who gets archived. What is true, and matters just as much: the switch is fully reversible at any time, disabling a member stops their future recordings from archiving immediately, and a later roster refresh never silently re-enables someone an admin switched off. If you're a member who wants out, the path is to ask your admin to switch you off, or email us directly and we'll route the request — both work, and we confirm back to you either way.

What actually happens when you remove the app

When the last admin on a Zoom account removes RecordFlow, Zoom sends us a deauthorization notice, and we delete the account's data in the same request that handles it — every member record, every admin's stored tokens, and the account's sync history, gone before we acknowledge the webhook. It isn't a queued job that runs sometime later; it's synchronous, comfortably inside the 30-day deletion window our Privacy Policy and Data Processing Addendum commit to. Two things are deliberately excluded from that deletion:

• The auto-delete audit log, but only for accounts that ever turned on the optional Auto-delete after archive feature — an immutable, INSERT-only record of each attempt to move a recording to Zoom's Trash, kept for 24 months for security and dispute resolution. It logs deletion attempts, not general sync activity, and never contains recording content.
• The recordings already sitting in your Google Drive — those are yours, in your Drive, and were never RecordFlow's to delete.

If other admins on the account still have RecordFlow installed, only the departing admin is offboarded; the account and its archive keep running for the rest of the team.

Where the files actually live — and who's responsible under GDPR

Every enrolled member's recordings land in their own named sub-folder under one Drive folder the admin connects — the archive root. A meeting Jane Smith hosted on June 4 lands at Your folder / Jane Smith / 2026 / 2026-06-04-Board meeting, the same layout described in our account-wide archiving post. That folder belongs to whoever's Google account authorized it, not to RecordFlow; we upload into it and never read from it again afterward. Under GDPR, that split is explicit: the admin's organization is the data controller for the recordings being archived, and RecordFlow is the processor acting on the controller's documented instructions, per Article 28. Our full processor obligations and sub-processor list are in the DPA linked above.

How RecordFlow fits

None of this is unusual for RecordFlow specifically — it's the shape any tool should take when it's handling recordings on behalf of people who never installed it themselves. We built the admin-managed app assuming a security reviewer would eventually ask these exact questions, and wrote this post instead of waiting for that email. None of the verification above changes what running RecordFlow day to day feels like: enrollment is still a toggle, archiving is still automatic once it's flipped, and nobody on the team has to think about it again. If your organization is evaluating RecordFlow for account-wide archiving, migrating off scattered individual installs, or archiving a multi-instructor academy's recordings alongside a storage cleanup, the same guarantees on this page apply everywhere in the product — nothing here is a special case written just for this post.