Azure DevOps Services and Server setup

Before connecting Azure DevOps

Use this page when the customer wants WebRiskOps to create or update Azure DevOps work items for report findings or fix tasks. Azure DevOps setup must separate Azure DevOps Services from Azure DevOps Server before WebRiskOps asks for organization, project, work item type or area path mapping. Start from `/settings` after Cloud and self-hosted integrations confirms the deployment mode. Do not save Azure DevOps credentials until the customer-owned organization, project, auth method and network path are clear.

Connect an Azure DevOps target

Follow the path `Cloud and self-hosted integrations → Azure DevOps target → Organization and project check → Work item mapping → Work management export or fallback`.

1. Open /settings and review Integration status, then choose Azure DevOps Services or Azure DevOps Server setup. Result: provider_key is recorded as azure_devops_services or azure_devops_server before project fields are requested.
2. For Azure DevOps Services, confirm the customer-owned dev.azure.com organization and choose OAuth or personal access token auth_method. Result: credentials are limited to the Azure Boards organization that will receive work items.
3. For Azure DevOps Server, enter base_url only after the customer confirms ownership, reachable collection/project API and scan or export authorization. Result: deployment_mode is self-hosted and private-network checks run before tokens are accepted.
4. Select organization and project for the work item destination. Result: WebRiskOps can discover the project process, work item types and required fields before export.
5. Confirm scopes for Work Items read/write, project metadata and field metadata. Result: WebRiskOps can validate work_item_type, area_path, iteration_path, priority and assignee mapping without asking for unrelated Azure DevOps access.
6. Review allowlist_status for Azure DevOps Server. Result: firewall, VPN or approved tunnel state is visible before WebRiskOps tries provider API calls.
7. Save only when provider auth, project mapping and network checks are ready. Result: the Azure DevOps target is available to work management export without exposing secrets in documentation or support messages.
8. If PROVIDER_AUTH_REQUIRED appears, reconnect OAuth or the personal access token before retrying. Result: the target stays blocked until valid credentials exist.
9. If PROVIDER_BASE_URL_BLOCKED or PROVIDER_SCOPE_UNAVAILABLE appears, fix the URL or scope, or use portable fallback. Result: unsafe server URLs and unavailable Azure DevOps permissions do not receive evidence.
10. Continue to Work management export after setup. Result: project, work_item_type, area_path and iteration_path mapping use the same Azure DevOps provider record.

Configure Azure DevOps authorization

Azure DevOps setup should collect only the access needed for the customer's export path.

• `azure_devops_services` is for Microsoft-hosted Azure DevOps Services organizations.
• `azure_devops_server` is for customer-owned Azure DevOps Server hosts that need a `base_url`, explicit authorization and network checks.
• `auth_method` should identify OAuth or personal access token setup before a credential is saved.
• `scopes` should allow Work Items create/update plus project and field metadata lookup, but not unrelated organization administration.
• `allowlist_status` should be clear before WebRiskOps retries self-hosted Azure DevOps Server API calls.
• Revoke access in Azure DevOps first, then disconnect the Azure DevOps target in WebRiskOps so historical work items keep references without keeping live credentials.

Ready Azure DevOps integration states

Continue only when the destination project and field mapping can safely receive export work.

• Azure DevOps Services ready means `provider_key` is `azure_devops_services`, the organization belongs to the customer and credentials are active.
• Azure DevOps Server ready means `provider_key` is `azure_devops_server`, `deployment_mode` is self-hosted and `base_url` passed URL safety checks.
• Project ready means `organization` and `project` identify the customer-owned Azure Boards project.
• Field mapping ready means `work_item_type`, `area_path`, `iteration_path`, priority and assignee mapping match the project process.
• Network ready means `allowlist_status` shows the Server target is reachable through a safe direct, allowlisted or customer-approved tunnel path.

Blocked Azure DevOps setup states

Blocked Azure DevOps setup should explain exactly what the customer can fix next.

• `PROVIDER_AUTH_REQUIRED` means reconnect OAuth or the personal access token before saving or retrying export.
• `PROVIDER_BASE_URL_BLOCKED` means the Azure DevOps Server URL failed ownership, redirect, DNS, reserved-IP or private-network checks.
• `PROVIDER_SCOPE_UNAVAILABLE` means the saved auth method cannot read project metadata, create work items or update existing work items.
• Missing `organization` or `project` means work management export cannot place the work item.
• Missing `work_item_type`, required custom fields, area path restrictions or inherited process rules can still block export after setup; those are handled on the Work management export page.

Continue after Azure DevOps setup

Continue to Work management export when the target is active and mapped to the customer project. Use Status sync and duplicate handling when an Azure DevOps work item already exists, Portable export fallbacks when Azure DevOps cannot be made safe, Jira Cloud and Jira Data Center setup when the team tracks remediation in Jira, or YouTrack Cloud and Server setup when the team uses YouTrack.