Integrations

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: 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:

​

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 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.

​

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. 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.