salesy.
On this page

Zoom App Review — Test Plan

Reviewer guide for validating the updated Zoom integration.

This page is written for the Zoom Marketplace review team. It walks through configuring and exercising every capability granted by the scopes in this update, using the development build of the Salesy app (the development Client ID is used in the authorization URL of our dev environment).

What's new in this update

Previously, Salesy could only receive transcripts from Zoom once a customer had manually enabled the correct recording and transcription settings. When those settings were wrong, no calls appeared and there was no explanation why.

This update adds an optional, user-initiated Connection Health check on the Zoom automation page. When a user runs it, Salesy:

  1. Reads the authorizing user's own Zoom meeting and phone settings to determine whether calls will actually be captured.
  2. Reports clearly which settings are correct, which are missing, and which require their Zoom admin's attention.
  3. Optionally fixes, only when the user explicitly asks, the one user-level setting Salesy is able to change — switching automatic recording to cloud so meetings are captured.

The user is always in control: nothing is read or changed until they click the button, and any change is shown to them first.

Scopes in this update and where each is exercised

| Scope | What it does | Where the reviewer sees it | |---|---|---| | user:read:settings | Reads the user's own meeting settings to audit recording/transcript config | Test 4 — Connection Health "read" step | | user:update:settings | Switches the user's automatic recording to cloud, only on request | Test 5 — "Fix my settings" step | | phone:read:user_setting | Confirms a Zoom Phone seat and reads user-level phone settings | Test 4 — phone section of the health report | | phone:read:user | Reads the user's phone profile for diagnostics | Test 4 — phone section of the health report | | phone:update:user_setting | Attempts to enable phone recording transcription, only on request | Test 6 — phone fix attempt | | cloud_recording:read:recording | Reads recording metadata as a backfill safety net if a webhook is missed | Test 3 — meeting ingestion | | cloud_recording:read:meeting_transcript | Downloads the meeting transcript file | Test 3 — meeting ingestion | | phone:read:recording_transcript | Downloads the Zoom Phone transcript | Test 3a — phone ingestion (optional) | | meeting:read:summary | Fetches the AI Companion meeting summary | Test 3b — AI Companion ingestion (optional) | | user:read:user | Reads the user's id + email to link the connection to their Salesy account | Test 2 — connection confirmed |

Prerequisites

  • Salesy development environment login — use the URL, email, password, and development Client ID delivered with this submission. Use the development URL, not go.salesy.app.
  • A Zoom Pro / Business / Enterprise account with cloud recording enabled. An AI Companion add-on and a Zoom Phone seat are optional (needed only for the optional tests).
  • The Zoom user that authorizes Salesy must be the same user that hosts the test meeting.

Test 1 — Authorize the development app (new-scope consent)

  1. Open the development environment URL from the reviewer packet and sign in with the reviewer credentials.
  2. Go to Automations, open the Zoom card (/dashboard/automations/zoom_oauth).
  3. On the Configuration tab, click Connect with Zoom.
  4. You are redirected to https://zoom.us/oauth/authorize?... — confirm the client_id in the URL matches the development Client ID from the reviewer packet.
  5. On the Zoom consent screen, confirm the scopes listed in the scope table above are all present, then click Allow.

Expected: You are returned to the Salesy Zoom automation page and it shows a Connected badge.

Test 2 — Connection confirmed (user:read:user)

  1. Stay on the Zoom automation page after Test 1.
  2. Open the connection detail / Active Integrations view.

Expected: The connected Zoom account's email is displayed, confirming Salesy read the user profile.

Test 3 — Meeting transcript ingestion (cloud_recording:read:meeting_transcript, cloud_recording:read:recording)

  1. As the same Zoom user that authorized in Test 1, host and cloud-record a short Zoom meeting with transcription enabled.
  2. End the meeting and wait 2–5 minutes for Zoom to finish processing.
  3. In Salesy, open Call history.

Expected: A new call appears with its transcript attached and analysis populated.

Test 3a — Zoom Phone transcript (optional, phone:read:recording_transcript)

If the reviewer account has a Zoom Phone seat with recording enabled, place a recorded Zoom Phone call, wait 2–5 minutes, and confirm the call appears in Call history with a phone transcript. If Zoom Phone is not available on the test account, note this and skip.

Test 3b — AI Companion summary (optional, meeting:read:summary)

If the reviewer account has AI Companion, host a meeting with the meeting summary enabled, end it, and confirm the summary is ingested into Call history. If AI Companion is not available, note this and skip.

Test 4 — Run the Connection Health check (user:read:settings, phone:read:user_setting, phone:read:user)

  1. On the Zoom automation page, click Check my Zoom settings (the Connection Health button).
  2. Salesy reads the authorizing user's own meeting and phone settings.

Expected: A health report is displayed listing which recording/transcript settings are correctly configured, which are missing, and which need admin action. The check runs only because the reviewer clicked it — nothing is read beforehand. No raw API errors are shown.

Test 5 — Fix meeting recording, on request (user:update:settings)

  1. Before running this test, in the Zoom web portal set Settings → Recording → Automatic recording to Off or Local so there is a fix to apply.
  2. Back in Salesy, run the Connection Health check (Test 4). It reports that automatic cloud recording is not enabled.
  3. Click Fix this setting. Salesy shows what it will change, then applies it.

Expected: Salesy switches the user's automatic recording to cloud, then re-reads the setting to confirm. The report updates to show the setting as configured. If the setting is locked by the account admin, Salesy instead displays a clear message that the admin must change it — it does not report a false success.

Test 6 — Attempt phone recording setup, on request (phone:update:user_setting)

  1. In the health report's Zoom Phone section, click Try to enable phone recording (shown only when a phone seat is detected and recording transcription is off).
  2. Salesy attempts the change on the user's own phone settings.

Expected: Salesy reports either success, or a clear message that the setting is controlled by the Zoom admin with guidance on what the admin must enable. A silent no-op from Zoom is treated as "admin action required," never as success.

Deauthorization

  1. In Zoom, go to Manage → Added Apps → Salesy → Remove (or disconnect from the Salesy Zoom automation page).
  2. Refresh the Salesy Zoom automation page and confirm it shows Disconnected.
  3. Optional: host another Zoom call and confirm no new analysis is created.

Troubleshooting

  • A meeting didn't appear. Confirm the connected Zoom user owns the recording, and that cloud recording + audio transcript are enabled in Zoom. Re-run the Connection Health check (Test 4) to see what's missing.
  • The consent screen shows the wrong Client ID. You are likely on go.salesy.app (production). Use the development environment URL delivered with this submission.
  • A "Fix this setting" action reports admin action required. The setting is locked above the user level in Zoom; this is expected on locked accounts and is reported honestly rather than as a false success.

Appendix A — API-level scope verification (if the Connection Health UI is unavailable)

If the Connection Health button has not yet been deployed to the development environment at the time of review, the new read/write scopes can be verified directly using the Zoom API Explorer or any HTTP client (curl, Postman, etc.) with the OAuth access token issued during Test 1.

  1. Complete the OAuth flow (Test 1) to obtain an access token.
  2. Issue the following calls and confirm the status codes:

| Scope | Request | Expected response | |---|---|---| | user:read:settings | GET https://api.zoom.us/v2/users/me/settings | 200 OK with a recording settings body | | phone:read:user_setting | GET https://api.zoom.us/v2/phone/users/me/settings | 200 OK (or 404 if account has no Phone seat) | | phone:read:user | GET https://api.zoom.us/v2/phone/users/me | 200 OK with user profile | | user:update:settings | PATCH https://api.zoom.us/v2/users/me/settings with body {"recording":{"auto_recording":"cloud"}} | 204 No Content | | phone:update:user_setting | PATCH https://api.zoom.us/v2/phone/users/me/settings with body {"auto_call_recording":{"enable":true,"recording_transcription":true}} | 204 No Content | | cloud_recording:read:recording | GET https://api.zoom.us/v2/users/me/recordings | 200 OK with recordings list |

All other scopes (cloud_recording:read:meeting_transcript, phone:read:recording_transcript, meeting:read:summary, user:read:user) are exercised through the end-to-end ingestion flow in Test 3.