Connect support cases to engineering work in Azure DevOps

Azure DevOps integration helps support and engineering follow the same customer issue without losing the support case’s history or ownership. An agent can create or link a work item, retain the relationship to the case and receive configured updates from the engineering project. This is especially useful when a B2B issue affects several contacts or customers but needs one coordinated engineering investigation. The relationship connects the work; your team still decides who owns the customer response, what can be shared and when to provide the next update.

Confirm current authorization compatibility first  ·  Agree the support-to-engineering operating model  ·  Connect and select the engineering projects  ·  Choose update volume, defaults and mappings deliberately  ·  Create a work item from the case  ·  Link existing engineering work instead of duplicating it  ·  Keep the customer commitment visible during engineering work  ·  Automate work-item submission only for a defined case situation  ·  Verify inbound updates and partial outcomes  ·  Troubleshoot the specific boundary

Confirm current authorization compatibility first

Core’s editor does not provide a personal-access-token (PAT) replacement field or an implemented Microsoft Entra OAuth migration procedure. Do not paste a PAT into an unrelated field, create a new legacy application from an old tutorial or assume that Microsoft’s recommended replacement authentication is already supported by this connector.

For an existing compatible connection, the Azure DevOps organization’s Third-party application access through OAuth policy applies to the legacy flow. Its authorized administrator manages it under Organization settings → Security → Policies. Review the policy through your approved process; do not turn on access broadly merely to bypass an unexplained connection error.

Official Microsoft references checked on 28 October 2026: legacy Azure DevOps OAuth, organization application-access policies, and authentication options. These OAuth instructions concern Azure DevOps Services; do not infer Azure DevOps Server support from separate Microsoft authentication alternatives.

Agree the support-to-engineering operating model

1. Identify the Azure DevOps organization, project and work-item type used for support investigations. An organization contains projects; they are not interchangeable selections.
2. Choose the account authorized to connect, and confirm access to the intended projects, work-item areas and operations. Project subscription setup also needs the provider’s View subscriptions and Edit subscriptions permissions.
3. In Supportbench, configuration requires integration-administration permission and section edit access. Agents need the relevant case access and Create and comment on DevOps items permission for supported provider actions.
4. Agree which case details and attachments engineering should receive. Review internal customer information and project membership before sending it to another system.
5. Define who owns the customer case while engineering works, which engineering updates should become Supportbench activities and what engineering states should mean for support.
6. Prepare a harmless representative case/work item and expected results, including a partial attachment failure and a state change that should not close a customer case unexpectedly.

Connect and select the engineering projects

1. Open Settings → Integrations → Azure DevOps. After confirming compatibility, select Connect Azure DevOps, or Reconnect for an existing connection.
2. Complete the legitimate authorization flow using the intended Microsoft/Azure DevOps identity. Review the requested access and return to Supportbench. If authorization is blocked or unavailable, resolve the compatibility or organization-policy issue with the integration owners.
3. Select Verify connection. This checks the saved authorization; it is not a test of arbitrary unsaved credentials.
4. Open Organizations and projects and select Add organization. Choose the Available organization and select Add. Within it, select Add project, choose the intended project and select Add.
5. Inspect each project’s subscription state. Core installs subscriptions for workitem.commented and workitem.updated. Use Repair when the project indicates incomplete subscriptions, then verify the result.
6. Configure General, Defaults and Field mappings, save the intended settings and complete the case/work-item test below before wider use.

If subscription repair fails, the provider administrator can inspect Project settings → Service hooks and the relevant history/test results. Refreshing a status display is not proof that a missing subscription was repaired. See Microsoft’s service-hook guidance.

Choose update volume, defaults and mappings deliberately

Engineering workflow states and customer service states may mean different things. “Done” in one project can mean development finished while customer validation is still outstanding. Agree the mapping with support and engineering, test representative values and avoid using a state name alone as proof that the customer accepted resolution.

Create a work item from the case

1. Open the intended case and read its latest activities and existing engineering relationships. Search for an existing work item before creating another investigation.
2. Select the relevant source activity when its content or attachments should be included. Review that activity and each file for the intended engineering audience.
3. Open Actions → Integrations and choose the Azure DevOps creation action. In the form headed Create Azure DevOps work item, select the intended Organization, Project and Work-item type.
4. Complete the dynamically loaded required fields and review the outgoing description. State the reproducible symptom, observed customer impact, what was tried and what engineering needs to determine. Do not copy an entire private case history without reviewing it.
5. Review selected source-activity attachments and any additional staged files. The supported creation path allows up to 25 MiB per file and 100 MiB total; provider/project constraints and upload outcomes still need to be checked.
6. Select Create Azure DevOps work item once. Read the result and any warnings. Verify the returned provider work-item ID and the relationship shown on the Supportbench case.
7. Open the actual engineering work item and confirm its project, fields, description and attachments. If creation succeeded but an attachment or follow-up link failed, inspect and repair that result before trying to create another work item.

Link existing engineering work instead of duplicating it

Use the case relationship workflow when engineering already has the relevant work item. This links the item to the case; it does not create a new item from the selected activity.

1. Open Actions → Case Relations → Link a Case.
2. Set Link type to Azure DevOps.
3. In Link existing Azure DevOps work item, choose the intended Organization. It must be active, configured and accessible.
4. Enter the numeric Work item ID. Compare the organization and ID with the authorized engineering record before submitting; similar titles across projects are not proof that two items are the same issue.
5. Select Link Azure DevOps work item. Read the result and verify the returned item identity and case relationship.
6. Open the provider item to confirm it represents the intended engineering work. If a relationship already exists, inspect it instead of creating a duplicate.

Unlink removes the Supportbench relationship; it does not delete the Azure DevOps work item. The Link a Case entry point requires case-edit and case bulk-link access, while the provider action also requires its Azure DevOps permission. An agent can therefore be permitted to create a work item while lacking this linking entry point. Review the intended permissions instead of using another customer’s case to work around access.

Keep the customer commitment visible during engineering work

• Record the engineering work-item reference and the specific question or action expected from engineering.
• Keep an accountable support owner and a next customer-update time. A linked work item is not an automatic ownership handoff.
• Review configured incoming activities for useful changes. Summarize engineering findings in customer language before sending a public reply.
• Check the actual case state after a mapped provider-state change. A state mapping can affect support work even when the engineering team intended only an internal development transition.
• Before resolving the customer case, verify the relevant fix, deployment or workaround and the agreed customer acceptance, rather than relying only on a provider status label.

Automate work-item submission only for a defined case situation

In Settings → Configuration → Workflows, the supported action is Submit Azure DevOps work item. Choose the appropriate Case trigger and narrow conditions, then configure the intended organization/project/type and required fields. The runtime validates the selected project/type and required data; a saved rule is not proof that every matching case can create a valid work item.

Use a controlled matching and nonmatching example. Consider repeated updates and other workflows before enabling a creation action: a rule that creates engineering work on every update can produce duplicate investigations. Confirm the resulting item, case relationship and any failure indication, then assign an owner for exceptions.

Verify inbound updates and partial outcomes

1. Create or link the approved sample work item and confirm both identities and the intended project subscriptions.
2. Make a controlled provider comment or state change that should be included by the selected activity policy. Inspect the resulting case and any mapped field/state.
3. Test an update that should be excluded by the chosen policy. Confirm the team does not receive unnecessary activity noise.
4. For state/dropdown mappings, test an exact supported value and an unmapped value. Case-state matching ignores case and surrounding spaces but requires a matching active state.
5. If no immediate update appears, inspect subscriptions, active connection state and delivery history. Updates are webhook-driven, and the runtime suppresses certain events immediately after linking and Supportbench-generated echoes. Do not promise instantaneous delivery.
6. When an operation reports a partial result, inspect the provider work item and saved case relationship before retrying. Record the known successful part and the remaining repair.

Troubleshoot the specific boundary

Continue learning

• Reference Azure DevOps connection and mapping controls
• Manage escalations and accountable return
• Work a case through to customer resolution
• Configure workflow triggers and actions
• Coordinate internal discussions and mentions