Collaboration spaces Module

Vaks PM · Integration guide · Microsoft Teams · Slack · Google Chat · July 2026

What collaboration-space provisioning does — and what it does not

• It triggers on project activation. A standard project entering the active state provisions a space with each enabled provider. There is no per-project opt-in flag — each provider's switch governs all standard projects.
• It keeps membership in sync as people join and leave the project, additively by default. Removing people from the space when they leave is a setting you turn on.
• Lifecycle on close depends on the provider. Microsoft Teams archives its team when the project closes (never deleted); Slack, Google Chat and the shared drive are not archived automatically (see Delete / unlink).

How Collaboration spaces works

Two independent paths lead to the same place. Outbound: Vaks itself creates the space through whichever provider you configured (Teams, Slack, Google Chat). Inbound: a tool that manages its own space (a Slack channel your team already owns, a Teams team provisioned outside Vaks, a Google space set up by another system) declares the link back. Both converge on the same record and the same panel on the project.

Providers are not identical in what they support: archive on close today only applies to Microsoft Teams (Slack channels and Google Chat spaces are created but not automatically archived when a project closes); public/private visibility is a Teams and Slack concept that Google Chat spaces don't have. An externally declared space is never touched by these lifecycle rules — only Vaks-provisioned ones are.

Prerequisites

Microsoft Teams is the identity-heaviest of the three — the table below is specific to it. Slack and Google Chat are lighter (no Entra/SSO dependency at all) and each has its own short prerequisites list in its setup section further down.

Step 1 — The Entra app registration

Create a new app registration in Microsoft Entra admin center → Identity → Applications → App registrations → New registration, single tenant, no redirect URI. It authenticates as itself with the client-credentials flow — no user is involved.

Under API permissions → Add a permission → Microsoft Graph → Application permissions, add:

Team.Create
TeamMember.ReadWrite.All
Channel.Create
TeamSettings.ReadWrite.All

Optionally add User.Read.All to help resolve identities. Then press Grant admin consent and confirm the status column reads Granted for each — application permissions do nothing until consented.

Collect the Directory (tenant) ID and Application (client) ID from Overview, and create a client secret under Certificates & secrets, copying its value at once.

Step 2 — In Vaks PM

Open Admin → Integrations → Collaboration spaces, choose Add a provider → Microsoft Teams, and configure it:

Step 3 — Test, then provision

Press Test on the provider card to confirm the credentials are accepted by Graph.

From here provisioning is automatic: activate a standard project and its team is created. Each project's Collaboration spaces panel also has manual buttons — Provision now, Re-sync, Archive — and shows the last few provisioning log entries with counts of members added and skipped.

Step 4 — SharePoint documents for agents and members (optional)

Each provisioned team has a SharePoint site behind it. This add-on lets AI agents working on the project — and project members who have access to the team — read those documents as live context: nothing is copied, and it is read-only. Members browse them under the SharePoint tab of the project's documents area; agents reach them through their working context.

It requires additional Graph permission on the app, in one of two models:

• Read-all (simpler): add Sites.Read.All to the provisioning app. One consent; Vaks PM restricts reads to the drives of provisioned teams.
• Selected-sites (tighter): the provisioning app holds Sites.FullControl.All and grants a second, minimal reader app Sites.Selected access to each team's site as it is provisioned. Agent reads go through the reader app, which can only see the sites it was granted.

Then enable it in two places — org-wide under Integrations → Collaboration spaces (on the SharePoint card: Enable SharePoint context, plus the identity model and, for the selected model, the reader app's client ID and secret), and per project (SharePoint document context, which also requires the project to have agents enabled).

Step 1 — The Slack app

Slack has no identity prerequisite — it needs a bot token and nothing else. Go to api.slack.com/apps → Create New App → From scratch, name it (e.g. Vaks PM) and pick the workspace it should live in.

Under OAuth & Permissions → Scopes → Bot Token Scopes, add:

channels:manage
groups:write
users:read.email

channels:manage creates and manages public channels, groups:write does the same for private ones, and users:read.email is how a project member's email is resolved to a Slack account for invites. Add whichever of the first two match the channel visibility you plan to use — both if you are not sure yet.

Scroll up to OAuth Tokens and press Install to Workspace (a workspace admin must approve if you are not one). Copy the Bot User OAuth Token — it starts with xoxb-.

Step 2 — In Vaks PM

Open Admin → Integrations → Collaboration spaces, choose Add a provider → Slack, and configure it:

Press Test to confirm the token is accepted, then activate a standard project to see its channel created — or, for a project that is already active, use the Provision now tool right on the Slack card (paste the project id) instead of cycling its status.

Step 1 — Google Cloud & Workspace

Google Chat is the heaviest of the three to set up, because the Chat API has no app-only mode: creating a space and adding members always requires a real Workspace user, so a service account has to impersonate one via domain-wide delegation. Expect a Google Cloud admin and a Workspace admin to be involved.

1. Enable the API. In a Google Cloud project (create one if needed), go to APIs & Services → Library, search Google Chat API, and enable it.
2. Configure the Chat app — do not skip this. Enabling the API is not enough: open the Configuration tab of the Google Chat API (console.cloud.google.com/apis/api/chat.googleapis.com/hangouts-chat) and fill in an app name, an avatar URL (any https image) and a description. Since Vaks only makes REST calls (never an interactive bot), leave interactive features off (otherwise Google demands a connection URL you don't have). Make the app visible to your domain. Without this, every Chat call returns "PERMISSION_DENIED — the resource doesn't exist", even with perfect delegation — it's the most common trap.
3. Create a service account. IAM & Admin → Service Accounts → Create Service Account. Note its email (…@….iam.gserviceaccount.com). Two authentication modes follow: service account key (download a JSON key via Keys → Add Key → JSON) or Workload Identity, keyless (nothing to download — see the dedicated section next, recommended if your organization blocks service account key creation).
4. Turn on domain-wide delegation. Still on the service account's page, check Enable Google Workspace Domain-wide Delegation and note the Client ID (a long number, not the email).
5. Authorize the scopes, in the Workspace admin console. In admin.google.com (a Workspace super admin is required here) → Security → API controls → Domain-wide delegation → Add new: paste the numeric Client ID, and these scopes:

   https://www.googleapis.com/auth/chat.spaces,https://www.googleapis.com/auth/chat.memberships

6. Pick a user to impersonate. Any real, licensed Workspace mailbox works — it is the identity the service account borrows to act as a human. An operations or automation account is a common choice; it just cannot be the service account itself.

Keyless — Workload Identity Federation (common to all Google integrations)

Many security-conscious organizations enforce the Google org policy iam.disableServiceAccountKeyCreation, which forbids downloading a service account key. There, the key method above is a wall. Vaks PM then offers a second authentication mode, Workload Identity Federation (WIF), which needs no downloaded key — the path a serious Google customer will accept.

How it works: Vaks signs an OIDC token with its own key (Google only knows its public half, pasted into the pool config), Google exchanges it for a federated token, then signs the domain-wide delegation assertion server-side. The key Vaks holds grants no access on its own: access is governed by the WIF config and an IAM grant, both revocable by you at any time.

This separation is deliberate: each integration has its own key, so you can rotate or revoke it without breaking the others. If you only run one integration in WIF, you obviously only have one provider to create.

Once per organization

1. Target the project (the ID, as text — not the number):

   gcloud config set project PROJECT_ID

2. Create the identity pool — once only, reused by every integration:

   gcloud iam workload-identity-pools create vaks --location=global --display-name="Vaks PM"

Once per integration

Repeat this block for each row of the table above that you enable. Every command on this page uses the same placeholders:

1. Keyless service account. The service account from Step 1 works — just don't create any JSON key. Domain-wide delegation (Client ID + scopes in Workspace admin) stays the one for the integration concerned.
2. Generate the signing key in Vaks. In that integration's card, switch Authentication to Workload Identity (keyless), then Generate signing key. Vaks shows the issuer, the kid and a public JWKS — the private key stays encrypted in the database, never exposed.

   Create the file in Cloud Shell. Between the two EOF markers, paste the exact contents of the card's "Public JWKS" field — the whole {"keys":[ … ]} block, verbatim, unchanged. This is not something to invent or copy from an example: it is your public key, the one carrying the kid shown on the card. (Quoting the first EOF stops the shell interpreting the content.)

   cat > jwks-PROVIDER_NAME.json <<'EOF'
   [[ PASTE HERE THE PUBLIC JWKS SHOWN ON THE CARD ]]
   EOF

   A JWKS holds public key material only — there is nothing secret to protect in this file. The kid it carries must be the one shown on the card: that is what lets you verify later that Google holds the right version.

   Prefer an editor? cloudshell edit jwks-PROVIDER_NAME.json. You can check the file is valid JSON with python3 -m json.tool jwks-PROVIDER_NAME.json.

3. Create the OIDC provider (inline JWKS, flag --jwk-json-path — not --jwks-json-file in recent gcloud):

   gcloud iam workload-identity-pools providers create-oidc PROVIDER_NAME \
     --location=global --workload-identity-pool=vaks \
     --issuer-uri="<ISSUER>" --jwk-json-path=jwks-PROVIDER_NAME.json \
     --attribute-mapping="google.subject=assertion.sub"

4. Let the pool impersonate the service account. This binding lives at the pool level, not the provider level: it identifies the service account by its subject, regardless of which provider the token came through. So if you reuse the same service account across integrations, one binding is enough — there is nothing to replay. Only redo it if the integration uses a different service account.

   gcloud iam service-accounts add-iam-policy-binding SA_EMAIL \
     --role=roles/iam.serviceAccountTokenCreator \
     --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/vaks/subject/SA_EMAIL"

   Note: SA_EMAIL appears in two places — the target service account (right after add-iam-policy-binding) and the member's subject/. Replace both with the same address.

5. Fill in the audience in the card: the full resource name of the provider you just created — it ends with PROVIDER_NAME, not with the pool name.

   //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/vaks/providers/PROVIDER_NAME

gcloud iam workload-identity-pools providers update-oidc PROVIDER_NAME \
  --location=global --workload-identity-pool=vaks \
  --jwk-json-path=jwks-PROVIDER_NAME.json

gcloud iam workload-identity-pools providers describe PROVIDER_NAME \
  --location=global --workload-identity-pool=vaks --format="value(oidc.jwksJson)"

https://www.googleapis.com/auth/chat.spaces,https://www.googleapis.com/auth/chat.memberships,https://www.googleapis.com/auth/drive

Step 2 — In Vaks PM

Open Admin → Integrations → Collaboration spaces, choose Add a provider → Google Chat, and configure it. First pick the Authentication mode: Service account key (the private-key field appears) or Workload Identity (keyless) (the audience field and the key-generation panel appear instead):

Press Test — it exchanges the service-account assertion for a token and does a small, read-only Chat API call, confirming the whole delegation chain works before anything is created. Then activate a standard project to see its space appear.

Delete a space, or unlink

Two actions live on each tile of a project's Collaboration spaces section, and they must not be confused:

https://www.googleapis.com/auth/chat.spaces,https://www.googleapis.com/auth/chat.memberships,https://www.googleapis.com/auth/chat.delete

Step 1 — Google Cloud & Workspace

Google Drive provisioning creates one shared drive per project — the Google equivalent of the SharePoint site that comes with a Teams team. As with Google Chat, a service account alone isn't enough: creating a shared drive requires a real Workspace user, so domain-wide impersonation is mandatory, whichever authentication mode you pick.

1. Enable the API. In your Google Cloud project, APIs & Services → Library → Google Drive API → enable.
2. Create a service account. IAM & Admin → Service Accounts. Note its email (…@….iam.gserviceaccount.com). Two authentication modes follow: service account key (Keys → Add Key → JSON) or Workload Identity, keyless.
3. Enable domain-wide delegation. On the service account page, tick Enable Google Workspace Domain-wide Delegation and note the Client ID (the long number, not the email).
4. Authorise the scope, in the Workspace admin console. admin.google.com → Security → API controls → Domain-wide delegation → Add new: paste the numeric Client ID, and this scope:

   https://www.googleapis.com/auth/drive

   This scope covers creating the drive and managing its members. It subsumes reading: a service account dedicated solely to reading documents only needs drive.readonly.
5. Pick a user to impersonate. Any real, licensed Workspace mailbox that is allowed to create shared drives. An operations account is a good fit.

Keyless mode (Workload Identity) for this integration

The principle and the pool are common to every Google integration — see Keyless — Workload Identity Federation for creating the pool (do that once). What follows is the block specific to Drive provisioning: it needs its own provider, because its issuer differs from Google Chat's.

1. In the Google Drive card (Step 2 below), switch Authentication to Workload Identity (keyless), then Generate signing key. The issuer shown ends with /federation/gdrive-provisioning; copy the JWKS into jwks-gdrive-prov.json.
2. Create the dedicated provider, inside the existing vaks pool:

   gcloud iam workload-identity-pools providers create-oidc vaks-gdrive-prov \
     --location=global --workload-identity-pool=vaks \
     --issuer-uri="https://YOUR-TENANT/federation/gdrive-provisioning" \
     --jwk-json-path=jwks-gdrive-prov.json \
     --attribute-mapping="google.subject=assertion.sub"

3. The impersonation grant lives on the pool: if the service account is already bound (for Google Chat, say), there is nothing to redo. Otherwise replay the add-iam-policy-binding from the shared section.
4. Paste this audience into the card's WIF pool audience field:

   //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/vaks/providers/vaks-gdrive-prov

Step 2 — In Vaks PM

Open Admin → Integrations → Collaboration spaces, then Add a provider → Google Drive. Pick the Authentication mode first: the form adapts (private key, or pool audience + key generation panel).

Click Test — the assertion is exchanged for a token and a small read-only Drive call is made, which validates the whole delegation chain before anything is created. Then activate a standard project to watch its drive appear. Re-provisioning a project that already has one creates nothing: it only re-syncs the members.

Membership sync

Membership is kept current in three ways: when project members or managers change, when the composition of an assigned team changes, and by a safety-net job that periodically reconciles every provisioned active project. Sync is add-only unless Remove on leaving is on, and it never removes the owner. Only active members with an Entra identity are added; everyone else is skipped and counted in the log.

Externally declared spaces

Everything above is Vaks creating the space (Microsoft Teams). The other direction exists too: a tool that creates the space itself — a Slack channel, a Google space, or a Teams team managed outside Vaks — declares the link back so it shows on the project. This path needs no Teams provisioning license.

It relies on an organization key restricted to the collab:link scope alone — deliberately narrow: the key can read and change nothing else on the project. Create it from Admin → Integrations → Collaboration spaces: add the Declared spaces API provider, which mints a key scoped to collab:link (the secret is shown only once).

{provider} is a free-form label (slack, google, teams…). The PUT body:

{
  "url": "https://…",         // required, https only, ≤ 2048 chars
  "externalId": "C0123ABCD",  // optional — the space's id in the tool
  "name": "Acme project"      // optional — display label
}

Troubleshooting

Provisioning is deliberately silent — it never breaks a project update — so the project's Collaboration spaces panel and its log are where you look. Server messages come back in French regardless of interface language, reproduced verbatim below.

Related: document sources, the full guide to SharePoint and Google Drive as read context · SCIM and OIDC, prerequisites for the Entra identity link · AI connector for the agents that read SharePoint context · all integrations.