> ## Documentation Index
> Fetch the complete documentation index at: https://docs.openmote.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations

> Connect the providers and tools that give Roomote the right context and operating surfaces.

Integrations do two different jobs in Roomote:

* some are workflow surfaces where teammates start or continue work, such as
  communications providers, source-control providers, and Linear
* others give Roomote more context inside a task, such as docs, tickets,
  monitoring, analytics, or data systems

Chat and source control are part of the core setup path. Most other
integrations are best added after the first environment and first task flow
already feel solid.

Keep provider types distinct during setup: communications providers handle
team conversations, source-control providers handle repositories and reviews,
inference providers run the model, and compute providers run task sandboxes.
This page focuses on workflow and context integrations.

## Workflow surfaces

These are configured from their own settings pages:

| Provider or surface                 | Where to configure            | What it enables                                     |
| ----------------------------------- | ----------------------------- | --------------------------------------------------- |
| Slack, Microsoft Teams, Telegram    | **Settings > Communications** | Starting and continuing tasks in team conversations |
| GitHub, GitLab, Gitea, Azure DevOps | **Settings > Environments**   | Repository access, PR review, and follow-up work    |
| Linear                              | **Settings > Integrations**   | Turning issues into Roomote work                    |

The Communications settings page manages the communications providers that
currently handle task conversations: Slack, Microsoft Teams, and Telegram.

## Context integrations

**Settings > Integrations** manages the built-in integrations that give tasks
extra context:

| Integration  | Best for                                          |
| ------------ | ------------------------------------------------- |
| Asana        | Project and task context from Asana               |
| Better Stack | Monitoring and incident context                   |
| Braintrust   | Prompts, runs, and evaluation context             |
| Grafana      | Dashboards, alerting, and monitoring context      |
| Jira         | Issues, projects, and JQL-backed issue context    |
| Linear       | Turning issues into Roomote work                  |
| Neon         | Database inspection in Neon                       |
| Notion       | Shared docs and database context                  |
| PostHog      | Product analytics, experiments, and error context |
| Pylon        | Customer issue and account context                |
| Railway      | Project and service context from Railway          |
| Sentry       | Error and performance investigation               |
| Snowflake    | Data warehouse exploration                        |
| Supabase     | Read-only database access in Supabase             |
| Supermemory  | Shared memory context across tasks                |
| Vercel       | Deployments, logs, and domain availability        |

## Connection patterns

You will usually see one of these setup models:

* **Admin connection once**: an admin connects the integration for the
  deployment from **Settings > Integrations**
* **Enable first, then teammates link accounts**: an admin enables the
  integration, then each teammate links their own account from
  [Personal Settings](/personal-settings) when they need it

## Manage available tools

Some connected integrations expose a **Manage tools** action in
**Settings > Integrations**. Admins can use it to restrict the types of
operations Roomote can make with the service.

Use this as a coarse permissions system — for example allowing only read
operations, or restricting access to a certain type of entity. The list varies
depending on the integration.

Some integrations can only list tools after the first user links their account
from [Personal Settings](/personal-settings).

## Custom MCP servers

Beyond the built-in catalog, environments can configure custom MCP servers so
tasks can reach tools that are specific to your team. Add them in the YAML
view of the environment editor — see [Environments](/environments).

Use deployment or user-linked integrations when the tool is broadly useful
across teams. Use an environment-level MCP server when the tool only makes
sense for one workspace, repository set, or self-hosted service.

## A practical order

For most teams, this order works well:

1. chat (Slack, Teams, or Telegram)
2. source control (GitHub, GitLab, Gitea, or Azure DevOps)
3. the first environment
4. one task-tracking integration (Linear, Jira, Asana) if your team already
   works there
5. one monitoring or data integration (Sentry, Grafana, Railway, Vercel) when
   investigations need it
6. one knowledge-base integration (Notion) to get tasks done directly from
   PRDs and other docs

After each connection, run a small task that uses the new context. For example,
ask Roomote to summarize a linked issue, inspect a monitoring alert, or explain
which repository a source-control thread belongs to.