From drowning in documentation to locating everything instantly with M365 Copilot.

Why Documentation Still Matters (Even When You Don’t Love Writing It)

I love documentation. Well, not really love it, I also think it’s kind of boring, but it’s essential. We need it. Because it is so annoying and frustrating to not know why you did something, what exactly you did, or how something works a while ago. Reinventing the wheel six months later is just one of the most frustrating things I’ve ever experienced.

It’s also super annoying to receive a solution from a colleague with no documentation. You end up with questions like: Why is this security role here? What does it do? What does this flow exactly do? How does it fit in with all the other components of this solution?

So, I love to write documentation just to make my life easier. And not just mine, it helps my colleagues too, and makes their lives easier.

The Real Problem: Finding Documentation Once You’ve Written It

I love writing documentation to help others and to help myself for later use. But the flip side is this: if there’s too much documentation, and other people don’t write as much as you do, things get messy. You come up with this whole structure, create subpages, move stuff around, and suddenly people are unable to find the documentation you have written anymore.

And then what happens? They stop using the documentation. They stop writing. They stop adding. Eventually, you’re the only one who’s actually on top of the documentation — and that’s not what you want. You want a team of people who all don’t mind writing documentation and can find the things you’ve written down easily, without having to search everywhere or, worse, not finding it at all.

The other day, one of my colleagues wasn’t able to find documentation and created a Jira ticket saying: “We should write documentation on this solution because currently we don’t have any.” Well, the documentation actually existed. He just couldn’t find it because the name of the solution wasn’t literally copied into the documentation. That’s super frustrating, and I don’t want that to happen.

This is exactly where I think Copilot can bridge the gap — by helping you find certain parts of documentation quickly and accurately.

From Chatbot Idea to the Microsoft 365 Copilot Connector

When I realized I could maybe use Copilot and some sort of chatbot to ask about my Azure DevOps Wiki, I was immediately drawn to it. I thought this could really help us: just ask Copilot what is this documentation, where is it, or what’s our current ALM strategy and get an instant answer.

At first, I considered pulling the entire wiki into a repo and using GitHub Copilot in Visual Studio Code. That works for developers, but not for everyone, and I wanted something easier and more accessible for the whole team.

While searching online, I quickly stumbled on the Microsoft 365 Copilot Connector, which extends Copilot with your Azure DevOps Wiki. I gave that a try, and even though I first thought in terms of building a separate agent, I realized extending M365 Copilot directly is actually perfect.

That’s what I’ll describe in the next pages.

Setting Up the Azure DevOps Wiki Connector

There’s actually a full Microsoft Learn documentation page that explains how to set this up. But I’m going to help you anyway, step by step. If you want to refer to the official documentation, you can check it out here: https://learn.microsoft.com/en-us/microsoftsearch/azure-devops-wiki-connector.

Step 1: Get the Right Privileges

You must have the Azure DevOps role: Search Administrator. Without this role, you won’t be able to continue.

Note: Even though I was a global admin in my own personal tenant and had all the other administrative roles, it still did not work. The only thing that made it work was the Search Administrator role.

Step 2: Enable Third-Party Application Access

In your Azure DevOps organization settings, switch on Third-party application access via OAuth under Application connection policies.

Step 3: Create the App Registration

In Entra ID, create a new app registration.

• Give it a proper name according to your naming conventions (e.g., wiki-agent-gbl-api).
• Add the required API permissions.

Note: Although I only needed to read my wiki, I still added the other read permissions as well. I tested whether they were necessary or not but couldn’t figure it out, so I left them in. They are all read-only, so it’s not a big problem.

Step 4: Configure Authentication (Part 1)

In the app registration, go to Authentication and enable ID tokens for implicit and hybrid flows.

Step 5: Configure Authentication (Part 2) – Redirect URL

Still in Authentication, add a platform:

• Select Web
• Add a redirect URL, e.g.:

https://gcs.office.com/v1.0/admin/oauth/callback

Step 6: Create a Client Secret

Create a client secret in the app registration and save the secret value somewhere safe. You’ll need this when creating the connector in Microsoft 365.

Step 7: Add the App Registration to Azure DevOps

Go to Azure DevOps → Users and add the app registration as a user:

• Assign Basic access level
• Give Project Reader permissions on the projects where your wiki lives

Step 8: Create the Connector in Microsoft 365 Admin Center

Go to the Microsoft 365 Admin Center → Copilot → Connectors and fill in the following fields:

• Display name
• Authentication type
• Client ID
• Client secret

Then select Authorize, and choose the correct organization.

Tip: If it doesn’t work and you still get an error, open Developer Tools (F12) in your browser and check. If you see a 403, go back and double-check all previous steps first.

Step 9: Authorize and Configure Access

Once you’ve authorized the connector and selected your organization, you have a couple of options.

One important setting is Rollout to Limited Audience. This is great if you want only certain people in your team to be able to use the connector. For example, I added just my own team here, so only they have access to the data coming from our wiki.

Step 10: Connector Starts Scraping Your Wiki

After you’ve made these changes, the connector is created and it starts scraping your Azure DevOps Wiki.

• It can take a little while for the first sync.
• You can also set future sync intervals (for example, every day or every 15 minutes). Usually, the defaults are fine.

Step 11: Start Using It in Microsoft 365 Copilot

At this point, you can go to your Microsoft 365 Copilot agent and start asking it questions about your Azure DevOps Wiki.

What you’ll see is that Copilot actually refers back to specific wiki pages when answering your questions. Super handy!

Note: You must have an M365 Copilot license to use this. Without it, you won’t be able to access the chat view and use the connector. This connector is really about extending Microsoft 365 Copilot, not creating a standalone Copilot agent.

Since I actually have not got a M365 Copilot license in my test tenant I am going to post a screenshot of another tenant but the idea is the same. Check the reference as well where you can directly go to your ADO wiki page, amazing!

Pitfalls, Daily Impact, and What’s Next

Before wrapping up, let me share a few important pitfalls I ran into:

• Double-check your rights and privileges in your tenant. You really need the Search Administrator role, or this won’t work.
• Don’t forget to give admin consent on the API permissions. I didn’t test skipping it, but it feels critical to have everything set correctly.
• In your app registration, under Authorization, make sure to tick the box for implicit grant and hybrid flows → ID tokens to be issued by the authorization endpoint. Without it, things will break.

With those pitfalls out of the way, let me say: I think this will really change my daily work with Copilot. Honestly, I wasn’t using Copilot as much as I wanted before, but now I can ask it about documentation — our solution documentation — and actually get useful answers. That’s going to save a lot of time, and I hope in the coming weeks I’ll already start seeing the impact.

And what’s next? For me, it’s Jira. We log bugs in Jira, not in Azure DevOps Wiki. The other day, a bug came up, and I asked Copilot if there was anything in the wiki that could help me fix it. Unfortunately, it didn’t help me enough. What if we log the solutions to bugs properly in Jira, and Copilot can use both the Azure DevOps Wiki and Jira tickets as sources? That would be a real game changer. That’s what I’ll be working on next, and I’ll definitely share what comes out of it.

About the Author

Felix Verduin

Senior Consultant at Powerbouwer | Power App specialist | Power Automate and Power BI advocate | IT enabler

Reference:

Verduin, F (2025). Excel on documentation with the ADO Wiki Connector in M365 Copilot [Accessed: 30th September 2025].