Every Jira team has repetitive tasks: assigning bugs to the QA lead, transitioning issues when a pull request is merged, sending notifications when a sprint starts. These tasks follow consistent rules, which makes them perfect for automation.

Jira's built-in automation engine lets you create rules without code. This guide covers how to identify automation candidates, build rules, and scale them across your organization.

Sprint planning is where most Agile teams either build momentum or lose it. A poorly run planning meeting produces a sprint full of half-finished stories, scope creep, and a team that stops trusting the process.

The problem is not Jira itself — it is how teams use Jira during planning. Without a structured workflow, the backlog becomes a dumping ground, story points become guesswork, and the sprint goal vanishes by Wednesday.

This guide walks through a complete sprint planning workflow in Jira, from backlog grooming to daily tracking, so your team ships predictably every two weeks.

The scenario every documentation team hits: you're writing a policy doc or technical spec in Confluence, and it needs numbered sections — 1. Introduction, 1.1 Overview, 1.2 Getting Started, 2. Configuration. So you type the numbers manually into each heading. Then product changes the structure: a section moves up, a new one gets inserted in the middle, and now every number below the change is wrong. You spend twenty minutes renumbering by hand, miss one, and the doc ships with 1.2 followed by 1.4.

Confluence has no native heading-numbering feature. Headings are just styled text — there's no automatic 1.1 / 1.2 scheme. Modern Numbered Headings for Confluence fixes this by generating numbered headings automatically from your H1-H6 structure, with a live preview and five numbering styles. When you reorder sections, the numbers update. This guide walks through setting it up.

The scenario every Jira team hits: a new bug comes in, and the reporter writes "it's broken" with no steps to reproduce, no environment, no severity. Or an incident gets logged without the services-affected checklist. You write a Confluence page titled "How to file a good bug," link to it from the project home, and nobody reads it. The tickets keep coming in malformed.

The real fix is to put the template on the ticket — so the moment someone opens Create Issue for a bug, the description already has the "Steps to reproduce / Expected / Actual / Environment" structure, the right labels, and the right assignee. That's per-issue templating, and Modern Issue Templates for Jira does exactly that. This guide covers three ways to create issues from templates, from quickest to most customized.

The scenario every engineering team hits: you're documenting an API in Confluence, and the page needs to show a JSON response, an XML config, a YAML deployment manifest, and a SQL query — all on the same page. You paste each one into Confluence's built-in code block macro, publish, and the result is a wall of monochrome text. No syntax colors. No line numbers that work. JSON braces, XML tags, and YAML indentation all blur together. The reader has to copy-paste your snippet into VS Code just to understand it.

The root problem is that Confluence's native code block uses a basic highlighter that wasn't built for the structured data formats modern teams actually work with. JSON, XML, YAML, and SQL each have specific visual conventions — matched braces, nested tags, indentation scopes — that a generic highlighter doesn't handle well.

Modern Code Blocks for Confluence solves this by bringing the Monaco Editor — the same engine that powers VS Code — into Confluence. It accurately highlights 85+ languages including JSON, XML, YAML, SQL, GraphQL, Terraform, Dockerfile, and every mainstream programming language. This guide walks through embedding formatted code and data formats in your Confluence pages.

Most Confluence users never see it, but every page is stored as an XML document in Confluence's storage format — a specific XHTML dialect with custom tags for macros, layouts, and embeddings. The visual editor hides this. But sometimes the only way to fix a problem is to edit that XML directly: a macro is corrupted and won't render, a copy-paste introduced broken formatting, or you need to find-and-replace a URL across a long page that the visual editor can't reach.

Confluence exposes the storage format through its REST API, but there's no built-in visual editor for it. Raw Storage Source Editor for Confluence adds one — a Monaco-powered editor that opens the raw storage XML of any page, with format, find-and-replace, and (in the Pro edition) a diff view. This guide covers when and how to use it safely.

Every team that adopts Jira diagrams hits the same moment: you discover Mermaid supports 29 diagram types, you get excited, and then you realize you have no idea which ones to actually use during a sprint. Most of them never get drawn. The diagrams that earn their keep are the ones that make a standup faster, an onboarding doc clearer, or a ticket unambiguous — and those are a small, repeatable subset.

This post is the workflow guide we wish we'd had: the four diagram types a sprint team actually uses, each with a real scenario and copy-paste syntax you can drop straight into a Jira issue. The full 29-type reference follows, so the same page works as both a sprint playbook and a complete catalog.

The scenario every Jira admin hits: there's a maintenance window Saturday night, a security policy change, or an ongoing incident — and you need every person who opens Jira to see it immediately. Jira has a built-in announcement banner, but it's plain-text only, lives in a buried admin setting, and gives you one banner at a time with no library, no scheduling, and no way to let users dismiss it.

Modern Announcement Banner for Jira fixes this: rich-text banners with emojis and custom colors, a dismissible option, a saved library of announcements you can switch between with one click, and instant enable/disable without deleting. This guide walks through setting it up.

Every architecture review ends the same way: the team sketches a system on a whiteboard, someone takes a blurry phone photo, and the diagram is never seen again. The next sprint a new engineer joins, asks how the system fits together, and the whiteboard gets redrawn from memory — different every time.

The fix is to capture the architecture sketch on the ticket it describes, editable by anyone on the team, versioned with the issue. That's what Excalidraw Diagrams plus Whiteboards for Jira does: it adds a full drawing canvas to every Jira issue, with 229 bundled shape libraries and freehand drawing. The same experience is available in Confluence via Excalidraw plus Whiteboards for Confluence. This guide walks through running an architecture session that produces a saved, shareable diagram.

The scenario every technical team hits: your engineering docs live in Markdown — READMEs, API references, design docs — and they contain diagrams (Mermaid), equations (LaTeX), and code samples. You paste that Markdown into Confluence, and it falls apart. The Mermaid code blocks render as plain text. The LaTeX equations show as raw $...$ syntax. The code blocks lose their syntax highlighting. Confluence's native editor is WYSIWYG, not Markdown, and the import tools treat Markdown as a one-time conversion rather than something you edit live.

Enhanced Markdown for Confluence solves this with a Markdown editor that renders everything inline — Mermaid diagrams, KaTeX and LaTeX math, syntax-highlighted code, and GitHub-flavored tables — with a live split preview. It runs on the Quikdown engine, so all rendering libraries are bundled locally (no external CDN dependencies, which matters for "Runs on Atlassian" compliance). This guide walks through writing Markdown in Confluence with diagrams, math, and code all rendering live.