Document sources

Vaks PM · Integration guide · SharePoint · Google Drive · July 2026

What you'll get. Documents that already live in SharePoint or Google Drive become readable from a Vaks PM project — by AI agents as working context, and by project members from the interface. Read-only, on demand, without ever copying a file.

What it does — and what it does not

A "document source" attaches external storage to a project so its content can serve as context. The scope is deliberately narrow, and the limits are the point.

It's a live proxy, not a sync. Nothing is copied, indexed or stored in Vaks PM: on each request the file is read at the provider and the extracted text is returned. Delete a file on your side and it leaves the context immediately.
It is read-only, always. No provider writes, renames or deletes anything. The Google Drive connector only requests the drive.readonly scope.
It does not replace attachments or the project's document space. These are files on your side, exposed for reading; attachments and the document space stay stored by Vaks PM.
Scope is the organization, activation is the project. A connector is configured once for the org; each project then decides whether to expose that context.
Only text comes back. Binaries that can't be extracted are refused cleanly rather than returned raw, and oversized files are bounded.

The two sources

Both implement the same internal contract, but their setup has nothing in common: SharePoint inherits an identity you already configured, Google Drive is a standalone connector.

	Microsoft SharePoint	Google Drive
Identity	Reuses the Microsoft Teams provisioning Graph identity — no secret to enter here.	Standalone connector: a Google service account, with its own configuration.
Prerequisite	A provisioned Teams team for the project (its site/drive is what gets read).	A Drive folder or Shared Drive, and a service account that can read it.
What is read	The drive of the project team's SharePoint site.	The project's shared drive if one was provisioned; otherwise the root folder you designate, and its tree.
Scope	Per project (each project has its own team).	Per project if you enable shared drive provisioning; otherwise per organization (one shared root folder), enabled project by project.
Configuration	Identity model only.	Auth mode, root folder, service account.

Both are configured in the same place: Admin → Integrations → Collaboration spaces, in the document-sources block at the bottom of the section.

Who reads, and how

Two audiences, two paths, two access rules — this is the distinction that matters:

AI agents read through the MCP tools vaks_list_context_files and vaks_get_context_file, scoped to a task. The project must have agents enabled.
Project members browse the same source from the project interface. There, project membership is what authorizes, not the agents flag.

In both cases, reading a file is recorded in the audit log (action filesource.document.read): you always know which document was opened, by whom, and on which task.

What allows a read

Every request passes a series of conditions; the first one missing produces an explicit refusal, never partial content.

Condition	Where it is set
Active licence	Admin → Organization → Licence
Source configured and enabled	Admin → Integrations → Collaboration spaces
Document context enabled for the project	Project tab — per-project switch
Agents enabled for the project (agent reads only)	Project AI tab
Project membership (human reads only)	Project members
Effective access at the provider	The SharePoint grant, or the Drive folder share

SharePoint — identity & access

SharePoint has no secret of its own: it borrows the Graph identity already configured for Microsoft Teams provisioning. So Teams must be configured, and the project must have a provisioned team — that team's site is what gets read.

The only choice is the identity model:

Model	What it implies
`read_all`	The provisioning application reads sites itself. Simplest, but the permission is broad: it covers every site in the tenant.
`selected_granter`	A separate "reader" application receives read access site by site, granted automatically on the one site of the team concerned. Far more restricted — the recommended choice when your security team looks closely.

Access is verified, not assumed: when a team is provisioned, Vaks PM resolves its site and drive and records whether the grant is in place. If it isn't, the project panel offers to re-check. The detailed Entra-side setup lives in the Collaboration spaces guide.

Google Drive — step 1, on the Google side

Unlike SharePoint, Google Drive depends on no provisioning: it needs a service account and a folder that account can read.

Enable the Drive API. In a Google Cloud project, APIs & Services → Library → Google Drive API → enable.
Create a service account. IAM & Admin → Service Accounts. Note its …@….iam.gserviceaccount.com email.
Give it access to the folder — two ways, your choice:
- Direct share (simplest): in Drive, share the folder (or Shared Drive) with the service account's email as Viewer. No delegation needed.
- Domain-wide delegation: authorize the service account's Client ID for the https://www.googleapis.com/auth/drive.readonly scope in admin.google.com → Security → API controls → Domain-wide delegation, then designate a user to impersonate. Useful when the folder can't be shared explicitly.
Get the root folder ID. Open the folder in Drive: the ID is the part of the URL after /folders/.

Without a service account key. If your organization enforces iam.disableServiceAccountKeyCreation, you won't be able to download a JSON key. The Drive connector then accepts Workload Identity Federation, exactly like Google Chat: nothing is downloaded, Vaks generates its own signing key and you paste the public JWKS into a WIF pool. The Google Cloud steps are identical — see the WIF section of the Collaboration spaces guide. In WIF mode, impersonation is mandatory.

Google Drive — step 2, in Vaks PM

Open Admin → Integrations → Collaboration spaces, scroll to the document-sources block, add Google Drive and fill in:

Field	What to enter
Authentication mode	Service account key (default) or Workload Identity Federation (keyless). The rest of the form adapts to your choice.
Root folder ID (organization fallback)	The ID from step 1. Everything readable is readable from this folder down, never above it. Ignored for projects that have their own provisioned shared drive — leave it blank if all your projects have one.
Service account key (key mode)	The JSON key file, pasted whole. Stored encrypted, never shown again.
Service account email (WIF mode)	The service account impersonated through federation — no key held.
WIF pool audience (WIF mode)	The WIF provider's full resource name, as `//iam.googleapis.com/projects/…/providers/…`.
Impersonated user	Required in WIF mode. In key mode, leave empty if the folder is shared directly with the service account.

Click Test: the connector obtains a token and lists the root folder, which validates authentication and real access to the folder before anyone depends on it. Then enable the connector.

Google-native files

A Google Docs, Sheets or Slides file has no downloadable binary — asking for one directly fails. The connector therefore exports them automatically as usable text: Docs and Slides as plain text, Sheets as CSV. It's transparent: an agent asking for a Google Docs gets its content, without having to know about this subtlety.

Other formats (PDF, Office, text…) follow the normal text-extraction path. A format nothing can be extracted from is refused explicitly rather than returned as binary.

API & AI tools

Route	Purpose
`GET /api/v1/tasks/{taskId}/context-files`	List a folder of the source attached to the task's project (paginated). Reachable by an agent token.
`GET /api/v1/tasks/{taskId}/context-files/{source}/{itemId}`	Extracted text of a file. Recorded in the audit log.
`GET /api/v1/projects/{id}/context-files`	Project-side equivalent for human browsing in the interface.
`GET /api/v1/projects/{id}/context-files/availability`	Tells whether a source is available for this project, and if not, why.

On the AI connector side, two tools are enough: vaks_list_context_files to browse, vaks_get_context_file to read. An agent always lists first to obtain an item's identifier.

Troubleshooting

Refusals carry a machine code, reproduced verbatim below — it says exactly which condition was missing.

Code	Cause & fix
`FS_DISABLED`	A switch is missing: licence, source disabled in admin, document context off on the project, or agents not enabled on the project (for an agent read). The message says which.
`FS_FORBIDDEN`	The caller has no access to this project. For a human, that's project membership; for an agent, the scope of its task.
`FS_SOURCE_UNAVAILABLE`	The source isn't resolved for this project — typically SharePoint with no provisioned team, so no drive to read.
`FS_GRANT_PENDING`	SharePoint: read access isn't (yet) granted on the site. Use the access re-check from the project panel.
`FS_AUTH_FAILED`	The provider refused authentication: invalid or unreadable service account key, missing delegation, or — in WIF mode — a misconfigured pool/audience.
`FS_ITEM_NOT_FOUND`	The item no longer exists, or isn't under the authorized root folder. Reminder: nothing above the root is reachable, by design.
`FS_FILE_TOO_LARGE`	The file exceeds the read limit. Extract the useful part into a smaller document.
`FS_UNSUPPORTED_FORMAT`	No text can be extracted from this format (image, archive, proprietary binary). Refused on purpose rather than returned raw.
`FS_THROTTLED`	The provider is rate-limiting. The read is retryable; space out the requests.

Test passes but an agent sees nothing? The test validates the connector (authentication + folder access), not the project switches. Check in order: the source is enabled in admin, document context is enabled on the project, and agents are enabled on that project.

See also: Collaboration spaces for the Teams provisioning SharePoint inherits its identity from · AI connector for the agents consuming this context · all integrations.