# Connect Slack Notifications
Generated: 2026-11-02T05:41:38.211Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: integrations.slack
title: Connect Slack Notifications
summary: Authorize the Slack workspace, test a personal message and inspect notification settings separately.
kind: quickstart
product_area: data_integrations
status: stable
updated: 2026-10-31
canonical: /docs/integrations/slack
---
# Connect Slack Notifications
## Prerequisites
Use the intended Slack workspace and an account permitted to install the app. A workspace owner or app manager may need to approve installation under your Slack policies.
## Authorize and test
1. Open **Admin → Integrations → Slack** and select **Connect Slack**.
2. Check the workspace on Slack's authorization screen and review requested permissions.
3. Complete any workspace approval and return to Teammately.
4. Confirm the displayed workspace and use **Send Test DM**.
5. Check the recipient's Slack account for the message.
A successful test means the provider accepted the request; checking Slack confirms receipt. Connection state, integration enablement and recipient preferences are separate conditions.
## Notification coverage
Supported milestones include Contribution plan readiness/completion, Reference Materials indexing, Case generation, evaluations, Goal Sessions and managed Harness starts. Delivery depends on enabled integration and recipient preferences. A test DM does not establish that every product event generates a notification.
## Recover delivery
For app approval, ask the Slack workspace owner/app manager to review the installation. For a failed test, inspect the reported result, intended workspace, app installation and recipient access. If a test succeeds but a product notification is absent, inspect the integration's enablement and recipient settings before reconnecting.
## Related reference pages
{% related-card-grid %}
- [Workspace Integrations](/docs/admin-console/integrations)
- [Microsoft Teams](/docs/integrations/teams)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
id: integrations.overview
title: Integrations
summary: Move Cases, source materials, external outputs, and benchmark results across Teammately's supported product boundaries.
kind: concept
product_area: data_integrations
status: stable
updated: 2026-10-30
canonical: /docs/integrations
---
# Integrations
## Definition
An integration connects customer-owned data or execution systems to a specific Teammately workflow. The useful boundary is not “send arbitrary records.” It is preserving enough identity, context, and version information for imported material to remain reviewable and for exported supporting information to remain interpretable.
## Choose the boundary
| need | Teammately boundary | preserve |
| --- | --- | --- |
| Bring behavior examples into a Project | Assets Cases or the Case import workflow | source identity, input, materials, attributes, current Project Input Schema |
| Give agents Project knowledge | Agent Setup → Reference Materials | source document identity, indexing state, intended use |
| Evaluate outputs produced elsewhere | Benchmark Evaluations → Import reference outputs | immutable Benchmark Version, exact Case IDs, output identity, measured telemetry |
| Send work to specialists | Expert Contributions and Expert UI | assignment, task context, Contribution state, Checkpoint, provenance |
| Use supporting information in another system | Run and Case result context | Run, Benchmark Version, Case version, Policy version, Rubric version, incomplete states |
Each pattern has a different lifecycle. Reference Materials are not Case materials. An external response is neither a Case-scoped reference output nor a Harness Version. A Contribution assignment is not a generic notification integration.
## Connection setup guides
| Need | Provider guides |
| --- | --- |
| Repository Reference Materials | [GitHub](/docs/integrations/github), [GitLab](/docs/integrations/gitlab), [Bitbucket Cloud](/docs/integrations/bitbucket) |
| Select tracing inputs for Cases | [Langfuse](/docs/integrations/langfuse), [LangSmith](/docs/integrations/langsmith) |
| Messaging | [Slack notifications](/docs/integrations/slack), [Microsoft Teams installation and tests](/docs/integrations/teams) |
| Training or inference access | [Provider credentials, identity and checks](/docs/integrations/training-and-inference) |
| Application/API automation | [Developer Guide](/docs/integrations/developer-tools), [SDKs](/docs/sdks), [CLI](/docs/cli), [REST](/docs/public-api) |
## Data movement principles
1. Read the owning product contract before transforming data. For Cases, start with Project Input Schema; for outputs, start with the immutable Benchmark Version.
2. Use backend-issued IDs as join keys and customer IDs as correlation keys.
3. Preserve versions when a downstream result depends on mutable source objects.
4. Distinguish acceptance from completion. Upload, artifact processing, evaluation, and expert work can have separate states.
5. Keep missing values missing. Do not turn unknown telemetry or incomplete evaluation into zero or false.
6. Reconcile a small sample before moving a full collection.
## Product UI and API boundaries
The product UI owns interactive setup, mapping, preview, conflict resolution, and human decisions. Automated integrations should use only a supported external contract that preserves the same object and version boundaries.
Internal browser endpoints, event payloads, database shapes, and service-to-service handlers are not customer integration contracts. Their presence in source code does not make them stable or safe to automate against.
{% example-demo title="External candidate evaluation" %}
A team produces assistant outputs in its own evaluation pipeline. It selects an immutable Benchmark Version, downloads the exact Case IDs, and maps one output to each Case. The imported output set becomes an output-only reference Run.
The team retains its own generation ID as correlation metadata while using the Teammately Run, Benchmark Version, and Case IDs as correctness-supporting information identity. Missing cost remains absent. The Run becomes interpretable after Rubric evaluation completes; successful upload alone is not a result.
{% /example-demo %}
## Private connectivity
Private connectivity is available as part of your Teammately deployment for data ingestion and model inference. [Ask us](https://teammately.ai/contact) about AWS PrivateLink, Azure Private Link, or equivalent connectivity for your environment.
Read [Admin Console](/docs/admin-console#private-connectivity) for the distinction between your network reaching Teammately and Teammately reaching your model endpoint.
## Fields, states, or lifecycle rules
- Projects scope reusable Cases, source materials, agent configuration, and correctness governance.
- Benchmark Versions freeze the Case and evaluator boundary used by a Run.
- API keys belong to organization administration and do not replace Project permissions.
- Imports and evaluations can be asynchronous.
- External outputs create non-Harness reference supporting information.
- Teammately supporting information informs customer review; it does not record a customer deployment decision.
## Related task pages
{% related-card-grid title="Integration workflows" %}
- [Import Case Examples](/docs/integrations/import-case-examples)
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Connect Model Outputs](/docs/integrations/connect-model-outputs)
- [Expert UI](/docs/integrations/reviewer-workspace)
- [Check candidate correctness](/docs/integrations/check-candidate-correctness)
{% /related-card-grid %}
---
id: admin-console.integrations
title: Workspace Integrations
summary: Connect messaging, repository, trace-store, and training services through their own authorization and operating controls.
kind: reference
product_area: admin_console
status: stable
updated: 2026-10-30
canonical: /docs/admin-console/integrations
---
# Workspace Integrations
## Definition
Open **Admin → Integrations** to connect workspace services. Each connection supplies a specific workflow rather than a general permission to read or write every external resource.
## Fields, states, or lifecycle rules
- Messaging connections support their configured notification and test operations.
- Repository connections discover repositories accessible to the authorizing account.
- Trace-store connections supply their supported capture/import workflow.
- Training connections are selected separately by a Benchmark preparation.
- Connection state, account authorization and a successful downstream operation remain distinct.
## Messaging
Slack and Microsoft Teams have provider-specific connection controls. For Teams, installation and a personal-message test are distinct operations. Workspace settings alone do not confirm installation or that automatic notifications are enabled.
Read provider errors as operational outcomes rather than treating a visible integration card as proof of delivery.
## Repositories and trace stores
GitHub.com, GitLab.com and Bitbucket Cloud connections discover the repositories allowed by the account and installation. Bind the intended repository through Reference Materials and inspect its indexed content.
LangSmith and Langfuse have their own connection surfaces. Keep original record identity and scope when importing material; connected access does not approve the captured behavior.
## Training and inference
Weights training selects an active service connection, supported model and compatible method. Connection checks do not certify quota, create-job permission, storage access or training quality.
Some evaluation paths require an existing callable inference deployment. A training job does not automatically allocate serving resources for every service. The deployment-to-output association can be user-reported where the adapter identifies it that way.
## Credentials and resource boundaries
For setup steps and provider-specific recovery, use the [integration guides](/docs/integrations#connection-setup-guides). Each guide distinguishes workspace connection, Project selection and a successful downstream operation.
Use the provider's owning connection flow and approved secret mechanism. Keep access scoped to the authorized account, identity and resource. Existing Vertex and Baseten training adapters do not authorize Google platform storage, ambient developer credentials or a provider fallback.
A failed service operation should remain actionable in its owning workflow rather than being hidden by a substitute local service.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Export, Train, and Evaluate](/docs/weights-training/exports-and-training)
- [Fieldloop](/docs/fieldloop)
- [Admin Console](/docs/admin-console)
{% /related-card-grid %}