Configure Azure DevOps integration

Updated Wednesday, October 28, 2026 · Marc Staine

Azure DevOps connects customer support cases to engineering work. Configure the authorized organization and projects, choose which engineering changes become Supportbench activities, and map compatible fields deliberately. A work-item link preserves context across teams; it does not replace the support owner, customer communication plan or acceptance of a resolution.

Applies to: Supportbench Core. Location: Settings → Integrations → Azure DevOps. Configuration requires integration administration permission and edit access to this settings section. Case operations and Azure DevOps project/subscription permissions are separate.

Before you begin

Confirm authentication compatibility with Supportbench before connecting or reconnecting. Core uses the configured legacy Azure DevOps OAuth application. Microsoft stopped new registrations in April 2025 and describes removal during 2026; this guide does not establish a precise removal date or guarantee a fresh authorization.
This editor has no personal-access-token replacement field or implemented Microsoft Entra OAuth migration procedure. Do not follow an old application-registration tutorial or enter a PAT into an unrelated field.
Identify the intended Azure DevOps identity, organization, projects and work-item types. The identity must be able to access the selected projects; subscription installation/repair needs the provider’s View subscriptions and Edit subscriptions permissions.
For an existing compatible legacy connection, have the organization administrator review Organization settings → Security → Policies → Third-party application access through OAuth through the approved process. Do not broadly enable access to bypass an unexplained error.
Agree which engineering events agents need and whether engineering state values have the same meaning as customer case states. Record current settings and prepare a representative case/work item for verification.

Configure and verify

Open Settings → Integrations → Azure DevOps. After compatibility is confirmed, select Connect Azure DevOps or Reconnect and authorize the intended provider identity. If the provider refuses the legacy flow, resolve that boundary before continuing.
Select Verify connection and inspect the result. It checks the saved authorization, rather than arbitrary unsaved credentials or whether every project subscription works.
Open Organizations and projects and select Add organization. Choose the Available organization and select Add.
Within that organization select Add project, choose the intended project and select Add. Check its active state and that both comment and update subscriptions were established.
If a project shows Repair required, use its Repair action and inspect the result. Check provider permissions and Service hooks if either subscription remains missing.
Open General. Set Display name, Create Supportbench activities for, Map Azure DevOps state to and Allow agents and workflows to use this connection deliberately.
Open Defaults and enter the intended Organization, Project, Work item type and Area path. Use provider values the selected project actually supports.
Open Field mappings. For each needed mapping, enter the Azure field reference name and choose a compatible Supportbench destination. Leave unused mappings unused rather than inventing fields.
Use the settings toolbar Save action. Reopen the editor to verify the saved choices, then run the representative case/work-item test below.
Inspect Audit when investigating who changed configuration. Verify actual provider records and incoming case updates separately; a successful configuration save is not proof of end-to-end operation.

Settings reference

Connection and General

Setting	What it controls	How to choose
Connect Azure DevOps / Reconnect	Starts the configured provider authorization flow.	Confirm legacy OAuth compatibility, approved identity and organization policy before using it.
Verify connection	Verifies saved connection credentials.	Inspect the returned result and test project operations separately.
Display name	Agent-facing name for this integration.	Use a recognizable engineering destination name.
Create Supportbench activities for	All work item updates; Comments and state changes; Comments only; or State changes only.	Choose the information agents need to act on. More events can create noise; no universal default is prescribed here.
Map Azure DevOps state to	Routes inbound state values to Case state or a supported active Case dropdown.	Use compatible values. Case state matching requires an active matching state name, ignoring case and surrounding spaces; it does not create new states.
Allow agents and workflows to use this connection	Active connection gate for supported operations and inbound processing.	Review dependent work before changing it, then verify the actual permitted behavior.

Defaults and Field mappings

Setting	What it controls	How to choose
Organization	Default provider organization for supported work-item actions.	Use an accessible configured organization; inspect the actual selection in the creation form.
Project	Default engineering project.	Confirm it belongs to the intended organization and is available to the connected identity.
Work item type	Default provider type, such as the type your team uses for an investigation.	Use the project’s actual type and satisfy its required fields.
Area path	Default work-item area.	Use a valid path and confirm the intended engineering team can work it.
Field mappings	Up to five inbound Azure field reference names and corresponding Supportbench destinations.	Use reference names such as System.State, not arbitrary display labels. Test the value type and destination choices.

Organizations, projects and connection lifecycle

Setting	What it controls	How to choose
Add organization / Available organization / Add	Loads available provider organizations and adds the chosen one.	Include only organizations your support workflow requires.
Add project / Add	Adds the chosen project and installs comment and update subscriptions.	Verify workitem.commented and workitem.updated coverage and actual delivery.
Project active	Controls whether the configured project is active.	Check creation/linking and inbound effects with a controlled record after changing availability.
Subscriptions / Repair required / Repair	Shows subscription evidence and repairs incomplete project subscriptions.	Refreshing status alone does not repair delivery. Resolve provider access failures, then verify both subscriptions.
Remove project	Removes the selected project and its provider subscriptions.	Review affected cases and workflows first; this is not deletion of the provider work items.
Remove organization	Removes its configured projects and subscriptions as well.	Review the entire organization scope before confirming.
Disconnect Azure DevOps	Removes this Supportbench connection and associated integration configuration.	Read the confirmation and plan how outstanding engineering relationships will be managed. Do not interpret this as deleting Azure work items.
Audit	Configuration creation/modification information.	Use it to investigate settings changes; it is not an end-to-end work-item delivery ledger.

Behavior to know

Save applies the General, Defaults and Field mappings edits. Adding/removing organizations/projects, changing Project active, Repair and confirmed Disconnect Azure DevOps run immediately through their own actions; they are not staged for the final Save.
If removal or disconnection fails, inspect the remaining provider subscriptions and saved configuration before assuming nothing changed. Earlier remote subscription deletions may have succeeded before a later step failed.
An engineering state and a customer resolution state can mean different things. A development task being Done is not evidence that a customer has received or accepted the fix.
Creating a work item requires the supported provider capability, a writable case and Create and comment on DevOps items permission. Linking through Actions → Case Relations → Link a Case additionally requires the case bulk-link entry-point permission.
A creation form uses the selected/displayed activity context and supported attachments. Review outgoing information and the engineering project audience before submitting.
Incoming updates are webhook-driven. The runtime suppresses certain events shortly after linking and Supportbench-generated echoes; do not promise instantaneous appearance.
The current Defaults editor has no separate Priority field even though older material may mention one.
These authorization instructions concern Azure DevOps Services. Do not infer Azure DevOps Server compatibility from other Microsoft authentication options.

Recommended use

Keep an accountable support owner and next customer-update commitment after linking engineering work. Review incoming technical comments before writing a customer-facing explanation.
Start with the smallest useful activity policy. Test both an included event and an excluded event to assess usefulness and noise.
Assign owners for provider credentials, project subscription health and state/field mappings. Recheck the integration when project types or engineering workflow states change.
Keep a known successful work-item ID when repairing a partial creation result. Inspect its attachments and relationship before retrying, to avoid duplicate investigations.

Worked example: one equipment fault needs an engineering investigation

Choose a harmless representative case and approved engineering project. Record the intended organization, type, customer-safe description and source activity.
Have an authorized agent create or link the work item from the case. Confirm the provider ID, project, fields, attachments and Supportbench relationship.
Make a controlled provider comment or state change included by the selected activity policy. Inspect the resulting case activity and any mapped fields.
Test an event that should be excluded and a state that has no destination match. Verify that the outcome matches the intended support process.
Confirm that the support owner still knows who will update the customer and when. Resolve any compatibility, subscription, mapping or partial-upload issue before expanding use.

Troubleshooting

Problem	What to check
Connect or Reconnect is rejected	Check legacy OAuth compatibility and approved organization policy with the integration owners. This editor does not supply a PAT or Entra OAuth replacement route.
An organization or project cannot be selected	Check the connected identity, provider access and configured active organization/project.
Repair required remains	Check View subscriptions and Edit subscriptions permissions and Project settings → Service hooks results. Verify both supported events.
A default is not applied as expected	Inspect the actual creation form and its organization/project/type selection. A default is not an override of every explicit or prior selection.
A case state does not change	Check the mapping, active destination state and actual provider value, as well as connection/project/subscription state.
Customer cases change state too early	Review whether engineering completion and customer acceptance should use different states or a different destination field.
No activity arrives immediately after linking	Inspect timing, subscription delivery, selected activity policy and suppression behavior before treating the link as broken.
Work item exists but an attachment or relationship step failed	Read the partial-result warning and inspect the existing item before retrying creation.
An agent can create but cannot find Link a Case	Check the separate case-edit/bulk-link entry-point permissions as well as the provider permission.

Integrations → Use the data synchronization log
Organization → Configure agent roles and division access

For additional setup and usage context, see these related guides:

Azure DevOps

Was this article helpful?