Skip to main content
Azure DevOps support uses an organization plus either a deployment-owned personal access token, a Microsoft Entra service principal, or a delegated Microsoft account. Choose the PAT path for the fastest setup, the service principal path for a deployment identity, or delegated sign-in when access should follow a specific Azure DevOps user.

​
Choose an authentication method

​
Personal access token

Create a dedicated Azure DevOps bot or service-account user and give it access to the organization, projects, or repositories Roomote should use. Create a PAT for that identity with Code read/write permissions appropriate for cloning, branch creation, and commits. Enable Build read access for CI Failure Triage and Work Items read access for work-item comment triggers. Grant Service Hooks read and manage access so Roomote can configure repository, pull-request, work-item, and build event delivery. Save the organization and token in setup, deployment env vars, or local .env.local. Onboarding only asks for those two values by default:
Optional values:
ADO_BASE_URL defaults to https://dev.azure.com. ADO_USERNAME defaults to ado and is used as the Git-over-HTTPS username paired with the PAT.

​
Microsoft Entra service principal

Instead of ADO_TOKEN, configure an Entra application that has been added to the Azure DevOps organization and granted access to the required projects:
Roomote acquires short-lived bearer tokens with the client-credentials flow and uses them for Azure DevOps REST and Git operations. ADO_TENANT_ID falls back to R_MICROSOFT_TENANT_ID when the shared Microsoft tenant is configured. The service principal must be explicitly added to the Azure DevOps organization and given an appropriate access level and project permissions. Service hook webhook secrets are generated automatically when Roomote configures service hooks. Advanced values remain editable later in Settings → Source Control.

​
Required API permissions

Azure DevOps does not use Microsoft Entra application permissions for service principals. Add the service principal to the Azure DevOps organization, assign at least Basic access, and grant the required project and repository permissions in Azure DevOps.

​
Connect with your Microsoft account

Choose Connect with your Microsoft account in setup or Settings to authorize the Azure DevOps account that should own the deployment connection. Roomote stores the linked account reference with the deployment and refreshes its short-lived Entra access token as needed. The Entra client ID, client secret, and tenant ID are still required so Roomote can refresh the connection in background jobs. This mode uses the same app registration. Grant the linked user the required Azure DevOps organization, project, and repository access. Add the web redirect URI shown by Roomote to the app registration:
The linked account can be reconnected or replaced later in Settings. Switching to PAT or service-principal mode removes the inactive credential path from the deployment configuration.

​
Sync repositories

After the Azure DevOps values are available, open Settings, go to the Environments page, and use the Source Control section’s Azure DevOps sync button. Roomote lists repositories from:
Roomote stores the results as Azure DevOps repository rows. If the sync reports that Azure DevOps rejected the credential, confirm the service principal or linked user belongs to the organization and has the required Azure DevOps access level and project permissions. Azure DevOps-backed tasks clone from the synced repository row, so sync must run before launching an Azure DevOps-backed task. Worker tasks write host- and clone-path-scoped Azure DevOps credentials into the file-backed Git credential helper instead of exporting ADO_TOKEN into task shells.

​
Service hooks and automations

Roomote ensures service hooks on every synced Azure DevOps repository for:
  • pull request created/updated and PR comments (Review Code and task follow-up)
  • work item commented (@roomote on work items)
  • build completed (CI Failure Triage on failed default-branch builds)
Service hook webhook secrets are generated automatically. The deployment API must be reachable from Azure DevOps for those deliveries.

​
Mention Roomote on pull requests and work items

Mention @roomote in a pull request comment or a work item comment to talk to Roomote about it. Each pull request or work item is a Roomote session: Roomote reads the discussion, answers as a comment when no workspace is needed, and otherwise starts a task on the pull request’s source branch (or the project’s mapped repository for a work item) and reports back in the same discussion. Pull request replies stay in the comment thread the mention came from. The commenter must have a linked Azure DevOps account. Ask for a review in the mention (for example @roomote review this) and Roomote runs the Review Code automation’s structured review on the current head, posts the findings on the pull request, and reports back in the same discussion. Review Code does not require the repository to be mapped to an environment. When an environment includes the repository, the review runs there; otherwise, Roomote uses a plain checkout of the active synced repository.

​
Native pull request merging in sessions

Active members and admins can ask Roomote to read and complete a pull request in an active connected Azure DevOps Git repository without starting a coding task. The bounded get_pull_request and merge_pull_request tools require repositoryFullName as organization/project/repository, a positive pullRequestNumber, and the freshly read 40-character expectedHeadSha. mergeMethod can be noFastForward, squash, rebase, or rebaseMerge. Roomote completes a PR only after an explicit request in the current human message. It reads the PR immediately before the mutation, sends the expected source commit, never requests policy bypass or source-branch deletion, and reads the PR again before reporting success or retrying an ambiguous result. Azure DevOps remains authoritative for policies, reviews, permissions, and merge eligibility. These tools do not expose other branch/file writes or repository administration.

​
Current limits

Classic TFVC repositories and non-Git build repository types are not triaged. CI Failure Triage only investigates failed builds on each repository’s default branch, one active investigation per repository.

​
Verify setup

  1. sync Azure DevOps repositories from Settings
  2. create or update an environment from a synced repository
  3. start a small task and confirm Roomote can clone the repository
  4. confirm Roomote can push a branch when the task produces changes
  5. optionally enable CI Failure Triage and push a default-branch commit that fails CI to confirm a triage task starts