How to bulk edit Azure DevOps work items without Excel (works on Mac)

Wed, 14 Oct 2026 13:45:05 +0000

title: "How to bulk edit Azure DevOps work items without Excel (works on Mac)"
published: true
description: "Open in Excel needs the Office add-in and Windows. Three ways to edit many Azure DevOps work items at once: bulk edit in the query, CSV import, or a spreadsheet grid in the browser."
tags: azuredevops, productivity, agile, tutorial
canonical_url: https://jr-devtools.com/guides/bulk-edit-azure-devops-work-items-without-excel/

cover_image: https://jr-devtools.com/bulk-editor/screenshot-grid.png

Disclosure: I'm the developer of Bulk Editor, one of the options mentioned below. Originally published on jr-devtools.com.

“Open in Excel” relies on the Azure DevOps Office Integration add-in: Windows only, and a frequent source of TF80012-style errors and Excel crashes. If you're on a Mac, can't install the add-in, or just want it to work, here are three ways to edit many work items at once.

1. Bulk edit in the query results (built in)

In a query or backlog, select several work items (Shift- or Ctrl-click), open the context menu and choose Edit. You can set one or more fields to the same value for all selected items, for example a new iteration, state or assignee.

Good: built in, nothing to install. Limit: every selected item gets the same value, so it doesn't help when each row needs its own estimate, title or tag.

2. CSV export and import (built in)

Run a query, export it with Export to CSV, edit the file in any spreadsheet app, and bring it back with Boards → Work items → Import work items. Rows with an ID update existing items, rows without one create new items.

Good: works on any OS, handles different values per row. Limits: rich-text fields such as Description are exported as raw HTML; errors only show up at import time; and nothing warns you if someone changed a work item after your export.

3. A spreadsheet grid in the browser

Bulk Editor (made by me) opens a query, a backlog selection or any list of work items in a spreadsheet-like grid inside Azure DevOps:

type in cells, use Enter and Tab, paste a block copied from Excel, and undo;
pick lists, required fields, states and area/iteration paths come from your own process, and invalid values are flagged before you publish;
nothing is saved until you select Publish, and a row that someone else changed in the meantime is refused instead of overwritten;
rich-text fields are never flattened; export to a clean .xlsx without HTML tags;
Pro: import .xlsx back, add new work items and children, and change parents in tree queries.

Good: nothing to install on your computer, works on Mac and Linux, different values per row with validation. Limits: Azure DevOps Services only for now; Pro is paid ($12 per organization per month), with a free plan of 25 published work items per organization per month and a 14-day Pro trial.

Which one should I use?

You want to …	Use
Move 40 items to the next sprint	Bulk edit in the query
Create a few hundred items once, from a plan someone sent you	CSV import
Groom a backlog: different estimates, titles and owners per row, regularly	A grid in the browser
Keep working in Excel on Windows with formulas	Open in Excel still does that, if the add-in works for you

Not affiliated with Microsoft. “Azure DevOps”, “Excel” and “Office” are trademarks of Microsoft.

Alternatives to the DevLabs Pull Request Merge Conflict Extension (2026)

Wed, 14 Oct 2026 13:44:34 +0000

title: "Alternatives to the DevLabs Pull Request Merge Conflict Extension (2026)"
published: true
description: "Microsoft's DevLabs merge conflict extension for Azure DevOps is no longer maintained. An honest comparison of the alternatives: resolving locally, your IDE, and a maintained extension."
tags: azuredevops, git, devops, productivity
canonical_url: https://jr-devtools.com/guides/devlabs-merge-conflict-extension-alternatives/

cover_image: https://jr-devtools.com/merge-conflict-resolver/screenshot-editor.png

Originally published on jr-devtools.com.

For years, the free Pull Request Merge Conflict Extension from Microsoft DevLabs (ms-devlabs.conflicts-tab) was how teams resolved conflicts without leaving Azure DevOps. It is no longer maintained. Here's what's going on and what you can use instead.

Disclosure: we make Merge Conflict Resolver, one of the options below. We've tried to keep this comparison fair; corrections are welcome at support@jr-devtools.com. Last checked: October 2026.

Is the DevLabs extension still supported?

No. Its last update was in November 2023, and Microsoft wrote in the extension's Q&A that “there are no current development resources for this extension”. Questions like “Is this even supported anymore?” go unanswered. Since 2024 its reviews average about 1.6 out of 5. The most reported problems:

the tab freezes or keeps “taking longer than expected to load”, and work is lost when it crashes;
non-ASCII characters (ä, é, č, Hebrew, Chinese …) are changed, especially in UTF-8 and ANSI files;
you can only take a whole file from one side, not choose per conflict or keep both;
the resolution lives only in the pull request's merge commit, so reviewers and builds never see it;
large files such as package-lock.json, or many conflicts, make it hang.

It still works for some teams on simple conflicts, so there's no need to remove it in a hurry. But if you run into the problems above, there won't be a fix.

The alternatives

1. Resolve locally with Git (free)

Merge the target branch into your source branch, resolve in your editor, and push. See our step-by-step guide.

Good: free, always works, you can build and test before pushing. Less good: you need the repository cloned and a working Git setup; slow for a two-line fix or for someone else's pull request.

2. Your IDE's Git integration (free)

Visual Studio, VS Code and JetBrains IDEs all have 3-way merge editors. In Visual Studio, check out the source branch, merge the target branch from Git → Manage Branches, and resolve in the merge editor.

Good: comfortable editor with IntelliSense. Less good: same as locally: you need a clone, and it's per developer, not something a reviewer can do from the pull request.

3. Merge Conflict Resolver (free plan, Pro from $12 per organization per month)

Merge Conflict Resolver is an independent, actively maintained extension that adds a Resolve conflicts tab to pull requests, built to fix the problems above:

3-way editor (Monaco, the editor of VS Code) with Accept target / source / both per conflict;
drafts are saved in the browser, so a reload or crash never loses work;
UTF-8, UTF-8 with BOM, UTF-16 and Windows-1252 files and their line endings are written back byte for byte;
edit/delete, renames, binary files, Git LFS and submodules each get a clear choice;
stays responsive with hundreds of conflicts and multi-megabyte lockfiles;
Pro: commit the resolution to the source branch, a summary comment on the pull request, bulk and whitespace auto-resolve.

Good: no clone needed, anyone on the pull request can resolve. Less good: Azure DevOps Services only for now (not Azure DevOps Server); Pro is paid. The free plan covers 10 pull requests per organization per month, and every organization gets a 14-day Pro trial.

Side by side

DevLabs extension	Locally / IDE	Merge Conflict Resolver

Switching from the DevLabs extension

Both extensions can be installed side by side, so you can try before you remove anything. An organization admin installs Merge Conflict Resolver from the Visual Studio Marketplace; there's nothing to configure, and the 14-day Pro trial starts the first time someone opens the tab.