DEV Community: JR DevTools

Azure DevOps Excel add-in not working: Team tab missing, TF80012, Excel crashes

JR DevTools — Wed, 14 Oct 2026 13:36:51 +0000

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

Editing work items in Excel, and the Open in Excel button, both depend on the Azure DevOps Office Integration add-in. It's a COM add-in for Excel on Windows, and most problems come down to it being missing, disabled or holding a stale cache. Here are the fixes, roughly in the order you should try them.

1. There is no Team tab in Excel

The Team tab isn't part of Office; the add-in adds it.

Install Azure DevOps Office Integration 2019. It's a free download on the Visual Studio downloads page, and it's also installed with Visual Studio when you select the Office integration component. Close Excel while it installs.
Open Excel and go to File → Options → Add-ins. At the bottom, choose COM Add-ins in the Manage list and select Go. Tick Team Foundation Add-in.
If it isn't in that list, choose Disabled Items in the same Manage list. Excel can disable an add-in after it caused a crash; enable it there and restart Excel.

The Team tab only exists in the desktop version of Excel on Windows. Excel for the web and Excel for Mac don't support the add-in at all; see Azure DevOps work items in Excel on a Mac.

2. TF80012: "The document cannot be opened because there is a problem with the installation"

This usually means Excel can't load the add-in that the workbook was created with.

Check the add-in is enabled (step 2 above) and not under Disabled Items.
Repair or reinstall Azure DevOps Office Integration, then restart Windows.

3. Excel crashes or hangs right after you sign in

A common cause is a corrupt local cache of the add-in. Close Excel, delete the contents of these folders, and try again:

%LOCALAPPDATA%\Microsoft\Team Foundation\8.0\Cache
%LOCALAPPDATA%\Temp\Microsoft\Team Foundation\9.0\Cache

If it only fails for one organization, also remove the saved credentials for dev.azure.com in Windows Credential Manager, so the add-in asks you to sign in again.

4. "Open in Excel" does nothing or isn't there

The button comes from the Azure DevOps Open in Excel extension, which an organization admin has to install first.
It hands the query to Excel on your computer, so the Office Integration add-in must be installed and working (steps 1 to 3).
It works on query results; if nothing happens, check the add-in by opening Excel and using Team → New List directly.

Still stuck? Edit the work items without the add-in

If you mainly want to change many work items at once, you don't need Excel for it:

Bulk edit in the query results: select several items, open the context menu and choose Edit to set one or more fields to the same value.
CSV export and import: Export to CSV from a query, edit the file, and bring it back with Boards → Work items → Import Work Items.
A spreadsheet grid in the browser: Bulk Editor (made by me) opens a query in an editable grid inside Azure DevOps Services, with paste from Excel, validation before publishing and a clean .xlsx export. Nothing to install on your computer; there is a free plan.

A longer comparison of these options: How to bulk edit Azure DevOps work items without Excel.

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

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

JR DevTools — Sun, 11 Oct 2026 08:08:06 +0000

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)

JR DevTools — Fri, 09 Oct 2026 09:36:39 +0000

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
Resolve in the pull request, no clone	✔	–
Choose per conflict	Whole file only	✔
Work survives a reload or crash	–	✔
Encodings kept intact	Reported to break	Depends on editor
Reviewers and builds see the resolution	–	✔
Maintained	No (last update 2023)	✔
Price	Free	Free

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.

Related guides

Watch the 1-minute walkthrough with captions on YouTube.

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

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.

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

Watch the 1-minute walkthrough with captions on YouTube.

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