Recordings & Transcripts - Operator Manual

Enabling Recordings & Transcripts means configuring two systems: the Teams MCP Server, which captures meeting transcripts into the knowledge base, and the Unique platform, which presents them in the Recordings area. Both must point at the same knowledge-base root scope — that single shared value is the most common source of misconfiguration.

Prerequisites

Grant admin consent

Transcript capture needs two Microsoft Graph scopes that Microsoft classes as privileged, because they read meeting content: OnlineMeetingTranscript.Read.All and OnlineMeetingRecording.Read.All. Both require admin consent — users cannot approve them for themselves. Until an administrator has granted it, users see an error when they try to connect.

Capture runs on a different Entra ID app registration than a chat-only Teams MCP deployment, so consent granted for the chat-only app does not cover this feature. Use the URL below.

Recommended for most clients. When Unique runs Teams MCP with capture enabled, Unique provisions the Entra ID app registration for you. You only need to grant admin consent:

https://login.microsoftonline.com/organizations/adminconsent?client_id=8ddffb12-1579-4fa8-8844-ca122e4308bc

The consent prompt lists every scope the capture-enabled server requests — the chat and messaging scopes plus Calendars.Read, OnlineMeetings.Read, and the two meeting-content scopes above. The URL handles them in one step. For the full list with least-privilege justification, see Teams MCP - Permissions.

If your organization uses multiple Azure tenants, confirm you are granting consent for the correct directory. See Grant tenant-wide admin consent to an application for a tenant-specific admin consent URL; use application (client) ID .

Self-hosted deployments provision their own app registration instead — see Teams MCP - Authentication, and add the two meeting-content scopes to it.

Enable ingestion on the Teams MCP Server

Set UNIQUE_INTEGRATION=enabled. This registers the transcript ingestion pipeline and the four knowledge-base tools, and makes the Unique API and Zitadel configuration mandatory.

Subscription and webhook behaviour is configured with the following variables. Their lifecycle is described in the Technical Manual.

For the full Teams MCP variable reference, including the variables that are shared with chat-only deployments, see Teams MCP - Configuration.

Example Helm values

mcpConfig:
  unique:
    integration: enabled
    serviceAuthMode: cluster_local
    apiBaseUrl: http://api-gateway.unique:8080
    apiVersion: "2023-12-06"
    rootScopeId: scope_abc123xyz # must equal RECORDING_KB_SCOPE_ID
    userFetchConcurrency: 5
    ingestionServiceBaseUrl: http://node-ingestion.unique:8091
    serviceExtraHeaders:
      x-company-id: "<your-company-id>"
      x-user-id: "<your-service-account-user-id>"

For deployments outside the Unique cluster, use serviceAuthMode: external with an API key:

mcpConfig:
  unique:
    serviceAuthMode: external
    apiBaseUrl: https://api.unique.app
    serviceExtraHeaders:
      authorization: "Bearer <api-key>"
      x-app-id: "app-id"
      x-user-id: "user-id"
      x-company-id: "company-id"

Zitadel service account

Why it is required

Ingestion happens on behalf of the server, not the end user, so the Teams MCP Server needs its own identity against the Unique Public API. The service account is used to:

1. Resolve participants — look up meeting attendees in Unique by email or username

2. Create scopes — create the folder structure that holds each meeting

3. Set access permissions — grant the organiser and participants their access

4. Upload content — write the transcript and recording into the knowledge base

Credentials are passed as the x-company-id and x-user-id headers on every API request.

Creating the service account

1. Log in to Zitadel and select the organisation where meetings should be ingested

2. Create the service account — under Service Accounts, click New Service Account and give it a descriptive name (e.g. "Teams MCP Server Service Account")

3. Note the identifiers — the organisation ID becomes x-company-id, the service account user ID becomes x-user-id

4. Configure the headers in mcpConfig.unique.serviceExtraHeaders as shown above

Required roles

The Unique Public API authorises each request against the Zitadel roles of the calling identity. Grant both of the following roles to the service account in the target organisation:

Each operation maps to a downstream role check as follows:

Root scope

Why it is required

All meetings are ingested as child scopes under one root scope (folder), giving a single organisational entry point for Teams content and one place to manage its permissions and visibility. The Recordings area in Unique reads from exactly this scope.

Creating the root scope

The root scope must be created manually in the Unique platform before deploying — there is no automated provisioning for this step.

1. Log in to the Unique platform as an administrator

2. Create a new top-level scope (folder) with a descriptive name (e.g. "Teams Recordings") and note its ID — it starts with scope_

3. Grant the service account access — give the Zitadel service account MANAGE, READ, and WRITE on the root scope. This is a required manual step: the server cannot provision access on a scope it has no rights to

4. Configure both systems with the scope ID — UNIQUE_ROOT_SCOPE_ID on Teams MCP and RECORDING_KB_SCOPE_ID on the platform

On startup the server re-issues these three grants for its service user against the configured root scope. The call is additive, so re-affirming existing access on every boot is safe. If it is rejected — a wrong or missing scope ID, or a service account that was never granted management of the scope — the pod hard-fails at boot rather than surfacing the error mid-ingestion. Look for root scope <id> permission bootstrap failed in the startup logs.

Enable the Recordings area in Unique

The UI is gated by a feature flag and needs to know which scope to read from.

For Unique SaaS deployments, Unique applies the flag and both settings for you; confirm the root scope with your Unique contact.

Enablement checklist

1. Knowledge base

   1incomplete Root scope created in Unique, scope ID noted2incomplete Zitadel service account created with chat.admin.all and chat.knowledge.read3incomplete Service account granted MANAGE, READ, WRITE on the root scope

2. Microsoft Entra ID

   1incomplete OnlineMeetingTranscript.Read.All and OnlineMeetingRecording.Read.All added2incomplete Admin consent granted for both — see Grant admin consent3incomplete Teams meeting policy has transcription enabled

3. Teams MCP Server

   1incomplete RabbitMQ reachable2incomplete UNIQUE_INTEGRATION=enabled with the Unique API and service header values set3incomplete UNIQUE_ROOT_SCOPE_ID set to the root scope4incomplete Pod starts without root scope … permission bootstrap failed

4. Unique platform

   1incomplete FEATURE_FLAG_ENABLE_RECORDING_UN_19218 enabled2incomplete RECORDING_KB_SCOPE_ID equals UNIQUE_ROOT_SCOPE_ID3incomplete RECORDING_CHAT_SPACE_ID set if the Open chat action is wanted

5. Verification

   1incomplete A test user connects and calls verify_kb_integration_status, which reports active2incomplete A recorded, transcribed test meeting appears in the knowledge base under the root scope3incomplete The same meeting appears in the Recordings area, plays back, and shows its transcript

Troubleshooting

Related Documentation

• Recordings & Transcripts — what the feature is and who it is for

• Technical Manual — architecture, ingestion pipeline, subscription lifecycle, and tools

• FAQ — frequently asked questions

• Teams MCP - Operator Manual — deploying and operating the server itself

• Teams MCP - Configuration — the full environment variable reference

• Teams MCP - Authentication — Entra ID app registration and admin consent