Skip to main content

​
Why integrate Devin with Azure DevOps?

Integrating Devin with your Azure DevOps organization allows Devin to clone repositories, create pull requests, and collaborate effectively with your team. This integration enables Devin to work seamlessly within your existing development workflow. Unlike some other SCM integrations, Azure DevOps does not display third-party apps in the same way. Instead, all connection management is handled inside Devin under Enterprise Settings > Integrations.

​
Prerequisites

Before setting up the Azure DevOps integration, you will need to:
  1. Create a dedicated Azure DevOps user for Devin - Create a new Azure DevOps account specifically for Devin (e.g., [email protected]). This dedicated service account provides cleaner access management and audit trails.
  2. Grant AAD Global Admin privileges to the Devin user - The new Devin service account must have Azure Active Directory (AAD) Global Admin privileges. Microsoft restricts third-party application access unless a Global Admin grants tenant-level consent.
  3. Prepare for the connection flow - To complete the integration, you will need to be:
    • Signed into Devin with your personal account
    • Signed into Azure DevOps with the Devin service account (the new account with AAD Global Admin permissions)
Both browser sessions must be active during the integration setup process—your Devin account to initiate the connection, and the Devin service account in Azure DevOps to authorize the OAuth consent.

​
Authentication and Permissions

Devin uses OAuth 2.0 via Microsoft’s MSAL (Microsoft Authentication Library) to connect to Azure DevOps. The Devin service account must have AAD Global Admin privileges to complete the OAuth flow. Azure DevOps works through service accounts, so Devin connects using the authorized Devin user identity rather than a registered app.

​
RBAC and Permission Model

Devin’s integration with Azure DevOps is built with a strict Role-Based Access Control (RBAC) model that separates authentication and authorization. This ensures that Devin only accesses repositories explicitly allowed by enterprise admins. When you connect Azure DevOps to Devin:
  1. A connection record is created with the encrypted refresh token, linked to the user identity
  2. Devin generates permissions records to define which organizations, projects, and repositories are accessible
  3. At runtime, checks are performed across all repos and compared to the permissions list to enforce boundaries
For enterprise customers, permissions can be replicated across organizations, and all repository-level access is managed via the Devin Enterprise UI under Integrations.

​
Azure DevOps Hierarchy

Azure DevOps uses a three-level hierarchy: Organization > Project > Repository. Devin handles this structure internally and can discover and interact with repositories at any level, as long as the connected user has access.

​
Setting up the Integration

  1. Sign into both accounts:
    • Sign into your Devin account at app.devin.ai
    • In a separate browser or incognito window, sign into Azure DevOps with the Devin service account (the account with AAD Global Admin privileges)
  2. In your Enterprise Devin account, navigate to Settings > Enterprise Settings > Integrations
Azure DevOps Connected Accounts
  1. Once on the Integrations page, click the Connect to Azure DevOps button.
Connect To Azure DevOps
  1. This will open up a new browser tab, asking you to grant Devin permission to your Azure DevOps Organization. Ensure you are signed in with the Devin service account (the account with AAD Global Admin privileges).
Azure DevOps Permissions
  1. Once you have granted permissions, you will see your Azure DevOps integration, and your connected Repositories, back on the Integrations page in Enterprise Settings
Azure DevOps Integrated
  1. Now that Devin has access to your Azure DevOps, you can grant permissions to any/all Sub-Organizations within your Enterprise account. To do this, select Git Permissions in your Azure DevOps integration, choose a Sub-Organization, and grant permissions either at the Group or Repository level.
Azure DevOps Git Permissions
  1. For each Organization that has been granted permissions, navigate to Devin’s Settings > Devin’s Machine, click + Repository, and integrate the repositories into Devin’s Machine.

​
What Devin Can Access

Devin’s Azure DevOps integration is focused only on Git operations, including:
CapabilityDescription
List repositoriesView available repositories and their metadata
Read branchesAccess branch information and commit history
Create pull requestsOpen new PRs for code changes
View pull requestsAccess PR events, comments, and status
Push codePush new branches and commits to repositories

​
What Devin Cannot Access

The integration is deliberately scoped to Git-only functionality. Devin does not have access to:
  • Work items (boards)
  • Pipelines or builds
  • Test plans
  • Artifacts
  • Wiki
  • Service connections
If your organization requires Devin to support these additional areas in the future, that would require broader OAuth scopes and new provider logic. Please contact [email protected] to discuss your requirements.

​
Security Considerations

The system is designed around the principle of least privilege:
  • OAuth provides capability, RBAC enforces boundaries - OAuth grants the technical ability to access Azure DevOps, but an additional layer of git permissions enforces the actual access boundaries
  • Explicit access only - Devin never accesses repos or projects that are not explicitly granted in the Enterprise UI
  • Encrypted credentials - All refresh tokens are encrypted and securely stored
  • Audit trail - Using a dedicated service account makes it easier to track Devin’s activity in your Azure DevOps audit logs
  • Branch policies respected - Devin’s PRs are subject to the same branch policies and review requirements as any other contributor

​
Best Practices

  • Use the dedicated Devin service account - Always use the dedicated Azure DevOps account created for Devin rather than connecting with a personal account
  • Enable branch policies - Set up branch policies in Azure DevOps to ensure all changes go through proper review processes before being merged
  • Use repository-level permissions - Grant Devin access only to the specific repositories it needs, rather than organization-wide access
  • Monitor access logs - Regularly review Azure DevOps audit logs for Devin’s activity
  • Document your setup - Keep internal documentation of which repositories Devin has access to and why
We recommend setting up branch policies in Azure DevOps to ensure all changes go through proper review processes before being merged.
If your Microsoft Entra ID is integrated with your organization’s HRIS (Human Resources Information System), additional configuration steps may be required to complete the Azure DevOps integration. Please contact the Devin support team for assistance with advanced setup.

​
Troubleshooting

OAuth consent fails:
  • Verify that the Devin service account has AAD Global Admin privileges
  • Check that your Azure AD tenant allows third-party application consent
  • Ensure you’re signed into Azure DevOps with the Devin service account (not your personal account) when completing the OAuth flow
Devin cannot see my repositories:
  • Verify that the Devin service account has access to the repositories in Azure DevOps
  • Check that repository permissions have been granted in Devin’s Enterprise Settings
  • Ensure the repositories have been added to Devin’s Machine
Pull request creation fails:
  • Confirm that the Devin service account has contributor permissions on the target repository
  • Check that branch policies are not blocking the PR creation
  • Verify that the target branch exists and is accessible

​
Network Setup

If you have IP filtering enabled on your Azure DevOps instance, you will need to whitelist Devin’s IP addresses. For the most up-to-date list, see our IP whitelisting documentation.