27 posts tagged with "FAQ"

Graphviz has been the backbone of automated graph visualization for over three decades. Originally developed at AT&T Labs, it powers dependency graphs in build systems, call graphs in profilers, and database schemas in ORMs -- anywhere that diagrams need to be generated from structured data rather than drawn by hand. Graphviz Charts for Confluence brings that same engine directly into your Confluence pages, letting you write DOT language descriptions and get polished, auto-laid-out diagrams without leaving your wiki.

Mermaid gives Confluence teams access to 26 diagram types, all rendered from plain text inside a single macro. That breadth of choice is a strength, but it also raises a practical question: which diagram types should your team actually use, and when? Picking the wrong type makes documentation harder to read, not easier. This FAQ walks through every Mermaid diagram type, explains which ones matter most for software documentation, and helps you make the right call for each scenario.

Mermaid is the most popular text-based diagramming language for technical documentation. One line of code generates a flowchart. A few more produce a sequence diagram, ER diagram, or Gantt chart. Teams using Confluence can embed Mermaid diagrams directly on their pages, keeping diagrams alongside the documentation they illustrate.

FAQ sections are one of the most practical elements you can add to a Confluence page. Whether you are documenting product details, building an IT help desk resource, or writing an onboarding guide, a well-structured FAQ section lets readers find answers without scrolling through walls of text or pinging someone on Slack.

The problem is that Confluence does not give you a built-in way to create FAQ sections. Teams typically resort to manual workarounds: bullet lists, tables, or toggles built from expand macros. These methods work, sort of, but they are tedious to maintain, hard to reorder, and look inconsistent from page to page.

Modern FAQ for Confluence solves this by giving you a dedicated macro for building FAQ sections with drag-and-drop reordering, WYSIWYG editing, and two display themes. This guide walks through the entire process, provides ready-to-use templates, and shares best practices so your FAQ pages actually help people find what they need.

Managing a Jira instance at scale means sooner or later you will need to act on dozens, hundreds, or even thousands of issues at once. Whether you are migrating projects, cleaning up stale tickets, bulk-downloading attachments for an audit, or exporting an entire backlog for offline analysis, doing it one issue at a time is not realistic. Bulk operations let teams apply the same change across many issues simultaneously, saving hours of repetitive manual work and reducing the risk of inconsistency that comes with editing tickets individually.

However, bulk operations carry real risk. A single misconfigured bulk edit can change the status, assignee, or custom field value of hundreds of issues in seconds, and Jira does not offer a one-click undo. That is why understanding the right tools, permissions, safeguards, and workflows is critical before you run any bulk job. This FAQ covers the most common questions teams ask when planning and executing bulk operations in Jira, from safety and rollback strategies to performance tuning and permission requirements.

Confluence has been the go-to knowledge base and documentation platform for thousands of organizations. At its core, Confluence uses a WYSIWYG (What You See Is What You Get) editor that lets users format content visually -- clicking toolbar buttons for headings, bold text, tables, and macros without writing a single line of markup.

But an increasing number of teams are asking a different question: can we write Confluence content in Markdown instead?

Markdown is a lightweight plain-text formatting syntax originally created by John Gruber in 2004. It has become the default writing format for developers, technical writers, and content teams who work with Git repositories, static site generators, and API documentation. Its appeal is simple: you focus on structure and meaning rather than visual styling, and the formatted output is generated automatically.

Teams choose Markdown over WYSIWYG for several compelling reasons. Developer-heavy teams often already write in Markdown daily -- in README files, pull request descriptions, and documentation repos. Switching to a WYSIWYG editor for Confluence pages feels like a step backward. Markdown content is also plain text, which means it works seamlessly with version control systems like Git, diff tools, and automated pipelines. Finally, Markdown files are portable; the same .md file can be published to GitHub, a static site, or a Confluence page without reformatting.

On the other hand, WYSIWYG editing remains the better choice for non-technical users who prefer visual feedback, drag-and-drop file attachments, and toolbar-driven formatting. Many business teams have no interest in learning syntax rules, no matter how lightweight.

This FAQ addresses the most common questions teams have when evaluating Markdown versus WYSIWYG editing in Confluence, and explains how Enhanced Markdown for Confluence by NGPILOT bridges the gap between both worlds.