Azure DevOps work items in Excel on a Mac: what works and what doesn’t

JR DevTools — Wed, 07 Oct 2026 17:48:09 +0000

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

Short answer: the Azure DevOps Excel integration (the Team tab, Open in Excel, Publish and Refresh) is a Windows-only COM add-in. It doesn't exist for Excel for Mac or Excel for the web. You can still get work items into a spreadsheet and back on a Mac; here's how.

1. Export a query to CSV and open it in Excel

Run a query in Boards → Queries, open the … menu and choose Export to CSV. Excel for Mac (or Numbers) opens the file directly. Add columns to the query first with Column options, including Parent if you need the parent ID on each row.

Watch out: rich-text fields such as Description are exported as raw HTML, and the export is a snapshot. Nothing links it back to Azure DevOps.

2. Import your changes back with CSV

Save the edited sheet as CSV (UTF-8) and import it with Boards → Work items → Import Work Items. Rows with an ID update existing work items; rows without one create new items. Keep the ID and Work Item Type columns, and remove columns you didn't change so you don't overwrite fields by accident.

Two things to know: errors only show up during the import, and the import doesn't check whether someone changed a work item after you exported it. Their change is overwritten.

3. Change many items to the same value: bulk edit

For "move these 40 items to the next sprint", you don't need a spreadsheet at all. Select the items in a query or backlog, open the context menu and choose Edit to set one or more fields for all of them.

4. Edit in a spreadsheet grid in the browser

If you want the spreadsheet experience without the round trip, Bulk Editor (made by me) opens a query or backlog selection in an editable grid inside Azure DevOps Services, so it works the same on a Mac, Windows or Linux:

type in cells or paste a block copied from Excel for Mac;
pick lists, required fields and area/iteration paths come from your process, and invalid values are flagged before you publish;
a row that someone else changed in the meantime is refused instead of overwritten;
export a clean .xlsx without HTML tags, and (Pro) import it back.

There's 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 …	On a Mac, use
Share or analyse a list of work items	Export to CSV
Set one field to the same value on many items	Bulk edit in the query
Create a few hundred items once	CSV import
Edit different values per row, regularly	A grid in the browser

Also on Windows and the add-in gives you trouble? See Azure DevOps Excel add-in not working.

Related guides

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

How to resolve merge conflicts in an Azure DevOps pull request

JR DevTools — Tue, 06 Oct 2026 07:40:08 +0000

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

Your pull request says “Merge conflicts. Next steps: Manually resolve these conflicts and push new changes to the source branch.” Azure DevOps has no built-in conflict editor, so you have two options: resolve locally with Git, or resolve in the browser with an extension.

Why the conflict happens

Azure DevOps tries a test merge of your source branch into the target branch (for example main). When both branches changed the same lines of a file, or one deleted a file the other changed, Git can't decide which version wins. The pull request can't be completed until the conflict is resolved in the source branch.

Option 1: resolve locally with Git

This works everywhere and needs nothing but Git and an editor. Replace feature/my-branch and main with your source and target branch.

git fetch origin
git checkout feature/my-branch
git pull
git merge origin/main
# Git lists the conflicted files. Open each one, resolve the
# <<<<<<< / ======= / >>>>>>> blocks, then:
git add .
git commit
git push

After the push, the pull request updates and the conflict is gone. A few tips:

Use a 3-way merge editor instead of editing markers by hand: VS Code's merge editor, Visual Studio's Git Changes → Merge conflicts, or git mergetool.
Prefer merge over rebase for a branch others also use: a rebase rewrites history and needs a force-push, which can reset approvals and surprise teammates.
Watch your encodings. Files in Windows-1252/ANSI or UTF-16 can be damaged by editors that assume UTF-8. Check the diff before you push.
If Azure DevOps keeps showing “Checking for merge conflicts” after the push, refresh the page; the test merge runs again for every new commit.

Option 2: resolve in the browser

Cloning a large repository just to fix two lines is slow, and not everyone who reviews or completes pull requests has the repository locally. An extension can add a conflict editor to the pull request page.

Microsoft's DevLabs Pull Request Merge Conflict Extension used to be the usual choice, but it hasn't been updated since November 2023 and Microsoft says there are no development resources for it. See alternatives to the DevLabs extension.

Merge Conflict Resolver (made by me) adds a Resolve conflicts tab to every pull request:

Open the pull request and select the Resolve conflicts tab.
Pick a file. Target, source and result are shown side by side; non-conflicting changes are already merged.
Above each conflict, choose Accept target, Accept source or Accept both, or edit the result freely.
Select Mark as resolved. When the last file is done, Azure DevOps creates the merge with your resolutions.
Optional (Pro): Commit the resolution to the source branch, so reviewers, builds and branch policies see exactly what will be merged.

Your edits are saved as a draft in the browser, so a reload doesn't lose work, and encodings and line endings are written back exactly as they were. There's a free plan and a 14-day Pro trial.

Which option should I pick?

Situation	Best option
Complex conflict that needs building or running tests before you push	Locally
A few conflicting lines, or you don't have the repository cloned	In the browser
Someone else's pull request that you're reviewing or completing	In the browser
Hundreds of conflicts where one side should simply win	Either: `git checkout --theirs` / `--ours` locally, or bulk resolve in the browser

Related guides

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

DEV Community: JR DevTools

Azure DevOps work items in Excel on a Mac: what works and what doesn’t

1. Export a query to CSV and open it in Excel

2. Import your changes back with CSV

3. Change many items to the same value: bulk edit

4. Edit in a spreadsheet grid in the browser

Which one should I use?

Related guides

How to resolve merge conflicts in an Azure DevOps pull request

Why the conflict happens

Option 1: resolve locally with Git

Option 2: resolve in the browser

Which option should I pick?

Related guides