Publish Azure DevOps release notes to Confluence or the Wiki automatically

Short answer: Generate the release notes from work items inside Azure DevOps, then let a pipeline task write the result where your readers already look: an Azure DevOps Wiki page for engineering, a Confluence page for the wider company, an email or a Teams channel for customers and support. The work items stay the single source and publishing becomes a build step. Permissions cause more failures than formatting.

The Atlassian Community has a steady stream of questions along the lines of "we track work in Azure DevOps but our documentation lives in Confluence, how do we get release notes across?". The answers range from embedding live work item queries in Confluence with a connector app, to Smart Links, to a custom AI agent that drafts notes from user stories and posts them with the Confluence REST API. On the Azure DevOps side, blog posts about publishing to the Wiki from a pipeline all stumble over the same two things: the build service needs Contribute permission on the Wiki, and appending to one page versus creating a page per release.

Pick the target by who reads it

Most teams need two of these. Generate once, publish twice.

Target 1: Azure DevOps Wiki

A project Wiki is a Git repository with Markdown pages, so a pipeline can write to it with a Git push, the Wiki REST API, or a task that wraps either. Three decisions:

1. One page per release, or one growing page? One page per release ("Release Notes/2026-11/Release 4.12") keeps history readable and lets you link a specific release from a work item. A growing page is easier to subscribe to. Parent pages have to exist unless the task creates them.
2. Project Wiki or code Wiki? A code Wiki is published from a branch of a repository, so a commit to that branch is enough. Mind the [skip ci] marker if the branch also triggers builds.
3. Permissions. The identity that runs the pipeline, usually Project Collection Build Service or, with limited job authorization scope, [Project name] Build Service, needs Contribute on the Wiki. Every blog post and GitHub thread on wiki publishing that we read ran into this once.

Target 2: Confluence

Confluence Cloud and Data Center both accept pages through their REST API as storage-format HTML. Generate the release notes as HTML, then create or update the page. Things to decide:

• Static page or live embed? Connector apps can embed an Azure DevOps query that updates itself. That is useful for an internal status page and wrong for release notes, which must not change after publication. Release notes should be a snapshot.
• Page hierarchy. A parent "Release notes" page with one child per version mirrors the Wiki layout and keeps the Confluence search useful.
• Authentication. Use an API token for a service account, stored as a secret pipeline variable. Never a personal token.

Is Confluence a good tool for public-facing release notes? An Atlassian Community thread asks exactly that. It works for a logged-in customer portal. Anonymous public spaces are limited and the formatting is Confluence's rather than yours, so for public notes generate a PDF or HTML and host it on a page you control.

Target 3: Email and Microsoft Teams

For customers and support, the fastest path is an email with the release notes as HTML body and PDF attachment. Microsoft Teams channels each have an email address, so the same email posts the release notes into the channel where support and sales see it.

Doing all of this with one template

Bravo Notes is a paid Azure DevOps extension (30-day trial) with a build task that renders work items through a template and writes the output to one of several targets. The same saved template serves every target; only the task options change.

Build task options, per target

Parameters and the current date can be used in the Wiki page path, and missing parent pages are created automatically. The task can also attach a PDF version to the Wiki page and add the Markdown to the pipeline run summary, so the release notes travel with the run that produced them. The build task page and the Teams guide cover the details.

A template that works for all targets

# {{ param 'ProductName' }} {{ param 'ReleaseNumber' }}

Released {{ date 'dd mmmm yyyy' }} from build {{ env 'BUILD_BUILDNUMBER' }}.

{{#section 'feature'}}
## New features
{{#workItems orderBy='Priority'}}
### {{ field 'Title' }}
{{{ field 'Custom.ReleaseNoteText' }}}
{{/workItems}}
{{/section}}

{{#section 'bugfix'}}
## Fixed bugs
{{#workItems}}
- {{#link}}{{ field 'Title' }}{{/link}}
{{/workItems}}
{{/section}}

{{#section 'known-issue'}}
## Known issues
{{#workItems}}
- {{ field 'Title' }}
{{/workItems}}
{{/section}}

For customers, drop the link helper so the document does not point at your internal work items. Parameters such as ProductName are saved with the template; for values that change per run, such as the release number, read a pipeline variable with {{ env 'RELEASE_NUMBER' }} instead.

A pipeline that publishes to the Wiki and emails support

1. Build stage produces the artifact.
2. Bravo Notes task, source Compare with release environment (Production), output Markdown, target Wiki. Everything not yet in Production gets listed.
3. Second Bravo Notes task, same template, output HTML, target Email, recipients the support mailbox and the Teams channel address.
4. Deployment stage.

If the deployment fails, the Wiki page for the attempted release already exists, which an audit trail needs. Teams that prefer to publish only after a successful deployment move both tasks to the end of the deployment stage.

Frequently asked questions

Can a pipeline write to the Azure DevOps Wiki without an extension? Yes. A project Wiki is a Git repository, so a scripted git push or a call to the Wiki Pages REST API works. The build service still needs Contribute permission, and you still need something that produces the Markdown.

Can Confluence pull release notes from Azure DevOps by itself? Connector apps embed live queries, which is useful for dashboards but not for release notes that must not change after publication. A pipeline that pushes a finished page is the safer pattern.

How do I keep internal IDs out of customer-facing notes? Use a template without links and IDs, and a label that only includes work items with a customer-facing text field filled in. Keep internal and customer templates separate.

What permission does the Bravo Notes build task need for the Wiki? Contribute on the Wiki for the Project Collection Build Service, or for the project's build service account when job authorization scope is limited. For a YAML pipeline with limited scope to referenced repositories, reference the Wiki repository explicitly.

Can the same release notes be published to the Wiki and Confluence? Yes. Add the task twice with different output targets, or once per stage. The template is shared.