Google Drive Sensor

What it ingests

Files under a specific Drive folder — Docs, Sheets, Slides, uploaded binaries (PDF, DOCX, …) — optionally descending into nested folders. File-sidebar comments (including on PDFs) are ingested as their own events and become Comment entities in the ontology. Google Docs suggestions / markup are a different API and are not ingested.

The folder may live in a My Drive or in a Shared (Team) Drive; see Shared (Team) Drives for the extra permission step the latter needs.

Using this source to ingest Gemini meeting notes? Read Meeting notes and the per-organizer folder problem below first — a single folder_id captures one organizer's meetings and silently misses everyone else's. The Google Meet sensor reads the same Gemini output without that gap; Choosing a meeting-capture path compares the two.

Credential

References a google_service_account_json credential by id — the same vault type as the Google Meet source (both read the same service-account key JSON shape). Leave it blank to use application-default credentials (ADC).

curl -sS -X POST https://your-corveil-host/api/credentials \
  -H "Authorization: Bearer <admin>" -H "Content-Type: application/json" \
  -d '{"type":"google_service_account_json","name":"acme-drive-sa","secret":"{ ...key json... }"}'

Config fields

Key	Required	Notes
folder_id	yes	Drive folder ID to ingest. Files under this folder (and descendants, if recursive) are pulled. Works for My Drive and Shared (Team) Drive folders alike.
recursive	no	Descend into nested folders. Defaults to true.

The folder ID is the last path segment of the folder's Drive URL (https://drive.google.com/drive/folders/<folder_id>).

Provider-side setup

1. Create a service account and download its key JSON.
2. Enable the Google Drive API on the project.
3. Give the service account read access to the folder — either share the folder directly with the service account's email, or enable domain-wide delegation with the Drive readonly scope and impersonate a user who can see the folder.

Shared (Team) Drives

Folders in a Shared Drive — Google's older name for these is Team Drive — are supported, with one extra setup step and one behavior worth knowing.

Add the service account as a member of the Shared Drive. Open the drive in Drive → Manage members → add the service account's email with at least Viewer. Sharing an individual folder inside a Shared Drive is not always sufficient: Drive's access model treats the drive as the unit of membership, and a non-member service account is often told the folder does not exist rather than that it is forbidden.

The source scopes its search to the drive automatically. On every poll (and on Test connection) it looks up the configured folder, reads which drive the folder lives in, and — when that is a Shared Drive — searches that drive specifically (corpora=drive plus the drive id). Folders in a My Drive keep Drive's default search behavior. There is nothing to configure: point folder_id at a folder inside the Shared Drive and it is handled.

Getting the folder id

Open the folder in the Shared Drive and copy the last path segment of the URL, exactly as for a My Drive folder: https://drive.google.com/drive/folders/<folder_id>. Do not use the drive id from https://drive.google.com/drive/u/0/folders/... at the drive root unless that root really is the subtree you want to ingest.

Only files under the configured folder are ingested. A document elsewhere in the same Shared Drive is not picked up — point the source at the drive's root folder if you want the whole drive, and leave recursive at its default.

Meeting notes and the per-organizer folder problem

Gemini meeting notes are Google Docs, so this source can ingest them — which makes it an alternative to the Google Meet sensor for meeting capture. There is one topology detail that decides whether it works.

Gemini writes meeting notes into the organizer's My Drive — the Drive of whoever scheduled the meeting, not a shared or per-org location.

Because this source takes a single folder_id, pointing it at one person's meeting-notes folder captures that person's meetings and silently misses every meeting organized by anyone else. Nothing errors and nothing warns: the source is reading the folder you configured, correctly, and other people's notes are not in it.

This is easy to miss in a pilot. One person schedules the standups, their notes land in their My Drive, the source reads them, and the setup looks complete — until a second person schedules a meeting.

For team-wide capture, use a Shared Drive. Create one, have organizers save or move meeting notes into it, and point folder_id at a folder there. See Shared (Team) Drives above for the membership step — the service account must be a member of the drive, not merely have the folder shared with it.

A single My Drive folder is a single-organizer solution

If more than one person schedules meetings you care about, one folder_id on a My Drive will under-capture without telling you. Use a Shared Drive, or use the Meet sensor, which fans out across members and has no equivalent gap.

Either way, capture is gated upstream by your Workspace's Gemini note-taking policy: a meeting nobody transcribed produces no notes for this source to find. Choosing a meeting-capture path covers that gate and compares the two sources side by side.

Wire-up

POST /api/sensors

{
  "sensor_type": "googledrive",
  "name": "Acme Eng Docs",
  "config": { "folder_id": "1AbCdEfGhIjKlMnOpQrStUvWxYz", "recursive": true },
  "credentials": { "service_account_json": "<google_service_account_json credential id>" }
}

Verify

Run Test connection to confirm the folder is reachable with the supplied credential. Once polling, new or modified files in the folder appear as document events.

Drive stamps events with modifiedTime, which the source records as an ingest-fallback occurred-at (eligible for title-date inference) rather than a true source event time.

Troubleshooting

Test connection fails with "folder not found". Drive reports a Shared Drive the credential is not a member of as nonexistent, so this reads like a wrong folder id but usually is not. Check the id, then add the service account as a member of the Shared Drive (above).

Test connection passes but nothing is ingested. Test connection also runs a one-item probe of the folder and logs the result, so the two cases are distinguishable in the source logs — look for the googledrive validate ok line and its drive_id, corpora, and probe_items fields. probe_items=0 means the credential can reach the folder but sees nothing inside it (an empty folder, or files it has no access to); a populated probe points at the poll instead.

A file that existed before the source was created never appears. The poll cursor is Drive's modifiedTime. The first poll picks up everything currently in the folder; after that, only files modified at or after the cursor re-emit. An untouched file added to the folder before the source existed is covered by that first poll, but one whose modifiedTime predates a later cursor is not — use a backfill, or touch the file.

A file is listed but lands with no content. Each poll logs a googledrive poll complete summary with files_seen and per-reason empty counters (empty_by_permission_denied, empty_by_unsupported_mime, empty_by_export_exhausted, empty_by_other), plus one googledrive extraction outcome line per file naming the extraction path and error category. Google Forms, Drawings, and Sites have no plaintext export and are ingested as metadata-only entities by design.