Integrations

Azure DevOps Integration

Connect DevStride to an Azure DevOps organization to import work items and keep them in step with Azure DevOps.

Use the Azure DevOps integration when a team's work already lives in Azure DevOps Boards and you want it visible, plannable, and reportable in DevStride without re-keying it. DevStride imports the projects you choose, recreates their iterations as time boxes and boards, and then keeps the imported items current as work items change in Azure DevOps.

Setup has two stages: create a Credential that connects an Azure DevOps organization, then map that organization's projects and work item types onto your DevStride data model and import.

Azure DevOps Services (dev.azure.com)

The integration connects through Azure DevOps OAuth and reads your organization at dev.azure.com. There is no setup path for Azure DevOps Server (on-premises).

To reach the integration, open Configure Settings → Integrations → Azure DevOps. The Integrations group also lists Credentials, which is where the connection itself is made. You need Manage Integrations to see these entries.

Before you start

You need the Manage Integrations permission (Owner and Admin have it by default).
The Azure DevOps account you connect must be able to grant DevStride the vso.identity, vso.project_manage, and vso.work_full scopes, and must be allowed to create service hooks in each project you import. DevStride registers the hooks for you at the end of an import.
Every DevStride Item Type you map a work item type to must have point effort enabled with the Decimal type, because Azure DevOps Effort is carried across as points. DevStride refuses any other Item Type with Please select a work type that supports decimal point effort.
Your organization needs a default invite role. People who appear on imported work items but are not yet DevStride users are added with that role (see Users).
Syncing runs only while your DevStride subscription is active. Webhook-driven updates are skipped when the subscription is inactive.

Credentials

Credentials store the authorization DevStride uses to talk to Azure DevOps. The Credentials page and its Add Credential dialog are shared with the Jira integration; the steps are the same, with the Provider set to Azure DevOps:

Go to Configure Settings → Integrations → Credentials and click Add.
Enter a Label, set Provider to Azure DevOps, and click Create. An Azure DevOps sign-in popup opens; complete it to authorize DevStride.
Each Azure DevOps organization the account can reach appears under the credential. Click Connect next to the one you want. Once installed, the row offers Configure (which opens the Azure DevOps page) and Disconnect.

Use Edit on a credential to rename it or Delete it. Deleting a credential disconnects every organization installed through it (see Disconnecting).

If you open the Azure DevOps page before connecting an organization, you will see a Connect Azure DevOps prompt. Connect to get started takes you to the Credentials page.

1 - Pick the projects to set up

Once an organization is connected, open Configure Settings → Integrations → Azure DevOps. Each connected organization is an expandable section headed by its base URL, with these controls:

Raw config — view the mapping configuration as JSON.
Save changes — appears as soon as you have unsaved mapping edits.
A Configuration / Import Jobs toggle to switch between mapping setup and import history. A pulsing dot on Import Jobs means a job is still running.
Disconnect and + Connect another organization, both of which take you to the Credentials page.

Under Select projects to setup, every project in the organization is listed with its state and last-updated time. Toggle a project on to configure it. Turning a project on or off is saved immediately; everything else waits for Save changes.

2 - Map each enabled project

Expanding an enabled project shows its mapping form. Set the two project-level choices first:

Status Collection — Select a Status Collection that should be used to setup the boards for this project. DevStride uses it for the boards it creates from your iterations.
Workstream — Select a Workstream where the items for this project should be placed. Imported items that have no imported parent land here.

Teams

Under Azure DevOps Team → DevStride Team, each project team is listed. Team mapping decides which work items are imported at all, and which DevStride team they belong to: at import time DevStride reads each mapped team's area paths and imports only the work items whose Area Path is one of them, giving each item that DevStride team. Work items in areas that belong to no mapped team are not imported, and a project with no team mapped imports nothing.

Use Infer team mappings to fill this table. The per-row team picker is currently disabled in the UI, so inference is the way to populate it.

Work types

The Azure DevOps Work Types list shows the work item types from the project's process that live on a backlog: portfolio backlog types (Epic, Feature), the requirement backlog type (User Story, Product Backlog Item, or Requirement), the task backlog type, and the bug type. Other work item types are not offered and are not imported.

Select a work type, then choose the DevStride Item Type it should map to. Each work type shows how complete its mappings are as a percentage. For every mapped work type, open its sections and map:

Section	Maps	Notes
Statuses	Azure DevOps Work Item State → DevStride Board Status	Statuses come from the project's Status Collection, so pick that first. States in the Removed category are not listed.
Tags	Azure DevOps Tag → DevStride Tag	DevStride tags come from the Item Type's tag collection. Unmapped Azure DevOps tags are dropped on import.
Priority Levels	Azure DevOps Priority → DevStride Priority Level	The Azure DevOps side lists the work type's allowed Priority values; the DevStride side comes from the Item Type's priority collection.

Custom Fields are not mapped

A Custom Fields section (Map your Azure DevOps Fields to DevStride Custom Fields) appears in the form, but field mapping is not active for Azure DevOps: the section has no editor and nothing from it is saved or synced. Required custom fields on the target Item Type are filled with their default values on import.

Auto-map with Infer

Every level has an Infer button. Infer project mappings fills the whole project (teams, statuses, tags, and priorities for all work types); Infer all work types and Infer work type mappings match one or all work types to Item Types and fill their sections; and each section has its own Infer team / status / tag / priority mappings. The dropdown next to each button offers Infer by heuristics or Infer from another project, which copies exact matches from a project you already mapped and infers the rest. Inference never overwrites a mapping you already made, and you can run it more than once. Review the result before saving.

When your mappings are ready, click Save changes. If you leave the page with unsaved edits, DevStride warns you first.

3 - Import a project

Click Initiate import on a project. The button stays disabled while you have unsaved changes or another Azure DevOps job is still running. An import needs the project's Status Collection and Workstream set; DevStride tells you which one is missing.

Imports run as jobs that you can follow on the Import Jobs tab. Each row shows the job type, when it started and last updated, who started it, the latest message, and its status; expand a row for the job's input, output, progress, and any errors. The list refreshes every 30 seconds.

An import runs these steps in order:

Iterations — DevStride creates a Cadence named Iterations (two-week, overlapping time boxes allowed) and a Board Folder named after the project that uses your Status Collection. Each Azure DevOps iteration with start and finish dates becomes a time box in that cadence (with its board); an iteration without dates becomes a plain board named after the iteration. Both the parent Workstream and the board folder are opened to the whole organization at Editor level if they were not already.
Areas — the area paths of each mapped team are recorded so items can be assigned to teams.
Work items — for each mapped work type, in parent-before-child order, every work item in the mapped teams' area paths (except those in the Removed state) is imported, replaying its revision history so that the DevStride item's history reflects who changed what in Azure DevOps, and when.
Service hooks — DevStride registers webhooks on the project so changes keep flowing (see How sync works).

Azure DevOps is the source of truth for imported items

Items imported from Azure DevOps are overwritten by later Azure DevOps updates. Any local change you make in DevStride to a synced field can be replaced the next time the source work item changes.

If you change a project's mappings after it has already been imported, DevStride offers to Re-import that project so the new mappings take effect (No, I will do it later leaves existing items as they are).

What a work item becomes

Azure DevOps	DevStride
Work item type	Item Type (per your mapping), with the type's color
Title, Description	Title, Description
State	Board status (per your mapping)
Priority	Priority level (per your mapping)
Tags	Tags (per your mapping; unmapped tags are dropped)
Assigned To, Created By	Assignee, author
Start Date, Target Date	Start date, due date (both are cleared if the target date is before the start date)
Effort	Point effort
Parent link	Parent item, if the pair of Item Types is a permitted parent/child; otherwise the project's Workstream
Area	Team (via team mapping)
Iteration	Board or time box created from that iteration

Users

DevStride matches the people on a work item (creator, assignee, last changer) to DevStride users by email. Someone without a DevStride account is created as an imported user and added to your organization with the default invite role; an assignee is also added to the DevStride team mapped to the item's area. Changes are recorded in DevStride as made by that person, at the time they happened in Azure DevOps.

How sync works

At the end of each import, DevStride registers service hooks on the project for work item created, updated, deleted, and restored events. From then on:

A new work item of a mapped type is created in DevStride. Work items of unmapped types are ignored.
An updated work item is refreshed. DevStride re-reads the work item from Azure DevOps before applying anything, rather than trusting the webhook body, and skips events that are older than what it has already applied. If the item's type is no longer mapped, the DevStride item is archived.
A deleted work item is archived in DevStride; its children move up to the project's Workstream. A restored work item is unarchived.
A parent removed in Azure DevOps moves the item back to the project's Workstream. A parent you set by hand in DevStride is kept.
An item moved to a new iteration moves to the matching board or time box; DevStride creates the time box if it has not seen that iteration yet.

Sync is one-way, from Azure DevOps into DevStride. Nothing you change in DevStride is written back to Azure DevOps.

What does not sync

Comments, attachments, and work item history entries.
Custom fields (see the note under Work types).
Links other than parent/child (Related, Predecessor/Successor, and so on).
Work item types that are not on a backlog in the project's process (for example Test Case, Issue, Impediment).
Work items outside the mapped teams' area paths, and work items in the Removed state.
Any change made in DevStride, back to Azure DevOps.

Working with imported items

An item imported from Azure DevOps shows an imported badge with the Azure DevOps icon. Selecting it opens a popup with:

This item was imported from Azure DevOps (or This workstream houses items imported from Azure DevOps on the parent Workstream).
View source item — opens the work item in Azure DevOps.
Sync — re-reads the work item from Azure DevOps and applies any revisions DevStride has not yet seen. If the work item is gone, you are told This work item no longer exists in Azure DevOps, or DevStride can no longer read it.
Item Metadata, including the Azure DevOps URL.

Imported items are read-only in DevStride: you can open them, follow relationships and board links, and read everything, but synced fields cannot be edited and relationships and blockers cannot be changed from the DevStride side.

Disconnecting

You can disconnect at three levels. Each asks what to do with the items that came from Azure DevOps:

Remove association and keep items — items stay in DevStride as ordinary, editable items with no link back to Azure DevOps.
Permanently delete items — the imported items are deleted.

Both choices are irreversible; recovering the items means a full re-import.

Scope	Where	What happens
One project	Toggle the project off on the Azure DevOps page	Prompts for the item behavior if the project has been imported; a disable job runs
One organization	Disconnect next to the organization on the Credentials page	Removes the installation and its service hooks; Installation disconnection initiated. Please refresh in a few minutes.
The credential	Edit → Delete on the Credentials page	Disconnects every organization installed through the credential; Credential deletion initiated. Please refresh in a few minutes.

Troubleshooting

Symptom	Cause and fix
Initiate import is greyed out	You have unsaved changes (click Save changes), or another Azure DevOps job is still pending or running (wait for it on Import Jobs).
Please select a status collection to continue / Please select a workstream to continue	Set both project-level fields, save, then import.
Please select a work type that supports decimal point effort	Enable point effort with the Decimal type on the Item Type under Configure Settings → Data Model → Item Types, or pick another Item Type.
A project's work item types are missing from the list	Only backlog-level types (portfolio, requirement, task, and bug) are offered. Check the project's process configuration in Azure DevOps.
The import completes but brings in few or no items	Only work items whose Area Path belongs to a mapped team are imported. Map the missing teams (Infer team mappings), save, and re-import.
The import fails with Organization has no default invite role configured.	People on the work items could not be added as DevStride users. Set a default invite role for the organization and run the import again.
Changes in Azure DevOps stop arriving	Check that the project's service hooks still exist in Azure DevOps (Project settings → Service hooks) and that your DevStride subscription is active. Re-importing the project re-registers the hooks.
DevStride asks you to reconnect the integration	Azure DevOps reported that the stored authorization has expired or been revoked. Re-create the credential's connection under Configure Settings → Integrations → Credentials; syncing resumes on the next event.

Jira — the same Credentials page and mapping model
Item Types — enabling decimal point effort and permitted parents
Connect AI & the MCP Server — the MCP tools list_integration_installations, create_integration_installation, and submit_integration_job work with Azure DevOps installations too

Connected Apps

See which apps you have authorized through OAuth to act on your DevStride account — AI clients such as Claude or Cursor — and revoke any you no longer use.

Subscription & Billing

See your plan and who it counts, set up monthly card payments before your free trial ends, manage cards and billing details, download receipts and invoices, and know what happens if payment lapses.