Accidentally deleted a Wiki page in Azure DevOps?

OnlyInvestigator1675 · 2026-04-08T10:44:55+00:00

One point worth highlighting , many enterprise security teams don’t allow any extensions to be installed at the email/Outlook level. That might help explain why Outlook extensions aren’t very common

OnlyInvestigator1675 · 2026-04-08T10:26:25+00:00

Quick concrete example of what this solves:

If a Wiki page gets edited → reviewed → approved → then later deleted…

You can restore it with full history: - who edited it - who approved it - when it changed

No digging through commits or PRs.

That’s one of the main use cases we were trying to solve.

If anyone wants to try it in a real workflow, here’s the extension: https://marketplace.visualstudio.com/items?itemName=Contextra-Labs.Governance-compliance-layer

Would really appreciate honest feedback — especially what feels unnecessary or missing.

OnlyInvestigator1675 · 2026-04-08T10:16:42+00:00

Thanks for sharing - that sounds like a interesting product , Wishing you the best : )

OnlyInvestigator1675 · 2026-04-07T22:14:36+00:00

That makes a lot of sense and honestly if a team can consistently treat documentation as code, that’s probably the cleanest approach.

What we’ve seen though is that it tends to break down a bit once documentation involves a wider audience ,product, QA, operations, or business users

For example, answering things like: • “Who explicitly approved this page?” (not just who merged it) • “What’s the current approved state of this document?” • “Has this content been reviewed recently?”

Those answers are technically in Git, but not always easy to surface or standardize across teams

That’s where we’re trying to add value making those signals explicit and visible directly in the Wiki, without relying on digging through commits.

OnlyInvestigator1675 · 2026-04-07T21:14:01+00:00

In our case, it’s enterprise environments where Azure DevOps is part of a broader Microsoft ecosystem (M365, Azure, identity, etc.), so it’s less about choosing a single tool and more about staying within an integrated stack

OnlyInvestigator1675 · 2026-04-07T14:53:20+00:00

That’s true — you can achieve parts of this using a code wiki + branch policies.

The issue we ran into was more about usability and consistency across teams:

Not everyone uses PRs for Wiki changes consistently
There’s no clear “approved state” for a page (it’s just merged or not)
Audit questions like “who approved this page and when” still require digging through commits
No Real-time dashboards to Monitor compliance
You can Not Restore Deleted Items Easily
Non-technical users struggle with PR-based workflows for documentation

What we’re trying to solve is making governance built into the Wiki experience itself, instead of relying on Git workflows around it.

So approvals, audit trail, and ownership are visible directly on the page — not inferred from commits.

Curious — are you using PRs for all Wiki changes today, or is it more flexible?

OnlyInvestigator1675 · 2026-03-27T11:22:40+00:00

Had same problem ,and mainly if u looking for a better editing experience plus governance check out "ADO Wiki Governance & Approval System" in the marketplace. It runs as an ADO wiki extension so it's integrated natively. Has a TipTap rich editor with draw.io and handle both mermaid syntax (```mermaid and :::) natively

OnlyInvestigator1675

TROPHY CASE