Every team has Markdown lying around that Confluence needs: the README that became the service doc, the design doc drafted as a pull-request description, the runbook that lives in the repo. And every attempt to move it hits the same wall — Confluence's default editor does not parse Markdown. Paste a .md document and you get a wall of pipes, backticks, and asterisks that looks exactly like what it is: text nobody formatted.

The macro route dissolves the wall. Paste the document into a Markdown macro that actually parses it, watch it render in the preview pane, publish. This page is the workflow, end to end.

Every engineering page in Confluence eventually holds code — a curl from the runbook, the config that fixed the incident, the query the dashboard runs. And every one of those snippets has three natural enemies: the language dropdown in the macro dialog, the paste that loses its indentation, and the reader who cannot copy the thing without dragging across line numbers.

Markdown fences solve all three, because they make the code block text you type instead of an object you configure. ```bash, paste, ``` — done, highlighted, copyable. This guide shows the syntax, the theming behavior, and when fences beat the native macro.

Ask an engineer to document an algorithm in Confluence and watch what happens to the math: O(n log n) typed as plain text, x² pasted from a character map, and — for anything real — a screenshot from an online equation editor, blurry and already out of date. Confluence has no native LaTeX support, so every formula becomes either a compromise or an image.

It does not have to. With a Markdown macro on the page, Confluence renders real LaTeX — inline $...$, display $$...$$, fenced blocks with full align environments — and the equation stays text: searchable, theme-consistent, editable in seconds. This guide gives you the syntax and copy-paste examples for all three routes.

Meeting notes fail in one of two directions: they are so informal that nobody can find the decision a month later, or so formal that nobody takes them at all. The Confluence editor quietly encourages the second — formatting dialogs are the enemy of live note-taking.

Markdown flips it. In a split-pane editor, notes are keystrokes: two characters for a heading, pipes for a table row, backticks for a snippet — and the rendered page assembles itself in the right pane while you type. This guide ships the template and the habits that make notes pages worth opening later.

The integration doc says "the client calls the API, the API validates and responds" — four words, zero contracts, and the onboarding engineer asks "with what headers, in what order, and what if auth fails?" The code has the truth; the wiki has a paragraph. An API that can't be read as a transcript is an API nobody can safely operate.

Quick answer: document API flows in Confluence as Mermaid — sequenceDiagram for request/response order, packet-beta for wire-format frames, ZenUML for branch-heavy async flows — rendered by Mermaid Plus for Confluence. Each diagram type answers a different reader: what order, what's on the wire, what branches. This post gives you three copy-paste examples.

The onboarding doc says "check the architecture diagram" and the architecture diagram shows a monolith from 2023 that the team decommissioned in the spring. Nobody is lying — the draw.io file lives on one person's laptop, and the wiki holds a screenshot nobody owns. An architecture that only exists as a static export rots silently, because the thing you would edit is invisible to review.

Quick answer: document system architecture in Confluence as Mermaid text — C4Context for the system in context, architecture-beta for the deployment, block-beta for the topology you want laid out precisely — rendered by Mermaid Plus for Confluence. Every level stays an editable code block, so the wiki's architecture changes in the same review that changes the system. This post gives you three copy-paste examples.

The quarterly review loads a 14-tab spreadsheet to answer one question — "where do we actually spend our engineering time?" — because the wiki charts are stale screenshots from last quarter and the numbers table nobody reads. A dashboard is not a spreadsheet: it is the two charts that answer the two questions people keep asking.

Quick answer: build dashboard charts in Confluence with Mermaid pie and xychart-beta charts, rendered by Mermaid Plus for Confluence. Pie for shares, XY for trends — both as editable text that refreshes like code. This post gives you three copy-paste examples: an effort-share pie, a weekly trend XY, and a dual-series release dashboard.

A build fails at 4pm, and the fix's pipeline takes 40 minutes to re-run from the top because someone decided every stage needs to re-validate. That wasted hour is not a code problem — it is a documentation problem. Nobody could see the pipeline's shape, so nobody saw the retry loop and the gate that would have caught the failure three stages earlier.

Quick answer: put the pipeline's shape in Confluence as a Mermaid flowchart, rendered by Mermaid Plus for Confluence. Text-based, editable, diffable — a pipeline diagram that changes when your pipeline changes. This post gives you three copy-paste examples: the linear stage view, quality gates with retry loops, and the deploy-to-tag gitGraph that records what actually shipped.

Your team grows by two people. The new hires open the wiki and find the architecture doc: a screenshot of a whiteboard, dated 14 months ago, where PaymentService does everything except the thing the diagram says OrderService does. Day-1 onboarding just taught two people the wrong architecture.

Quick answer: keep the architecture in Confluence as a Mermaid class diagram, rendered by Mermaid Plus for Confluence and diffs like code. Classes, methods, interfaces, ownership — in editable text that updates when the code does. This post gives you three copy-paste examples: the onboarding service map, interface+implementation modules, and a request-flow sketch.

The meeting asks "who owns this feature?" and the answer is a Venn diagram by hand — drawn on a whiteboard, erased, redrawn, photographed, and lost. Two teams each built a piece of a shared workflow, and "the overlap" is exactly where the bugs and the SQL both landed. A decision framework is only useful while its picture survives the meeting; in Confluence as Mermaid text, it survives.

Quick answer: put decision frameworks in Confluence as Mermaid — venn-beta for set overlap, cynefin-beta for which operating mode a situation needs, quadrantChart for which item goes first — rendered by Mermaid Plus for Confluence. Each framework encodes a decision shape, and text keeps the picture attached to the decision record. This post gives you three copy-paste examples.