标签：#confluence

One of those questions that looks like it should have a one-click answer and does not. Here is exactly what Confluence Cloud can and cannot do with numbers, and how to pick between the three ways out. Short answer. A normal Confluence table cannot add anything up: there is no formula engine behind it, and the number on the page is whatever somebody typed. A Confluence database can show a total at the bottom of a field, including Sum and Average. Neither can calculate a value per row, so nothing in Confluence Cloud gives you a column that multiplies price by quantity. You have three ways out, and the right one depends on how often the numbers change. What Confluence actually does It is worth separating two things that look similar on a page, because the answer is different for each. Tables The classic table you get from the editor is a layout element. It stores text, numbers, links and macros in cells, it merges cells, it sorts columns for the reader. It does not compute. There is no cell reference, no formula bar, nothing that recalculates when a value changes. If a total sits in the bottom row, a person put it there, and it stays wrong until a person notices. This is not an oversight anyone forgot about. The request to add spreadsheet behaviour to Confluence tables is one of the older open items in Atlassian's public tracker, and it is still open. Databases Databases are the newer structured-data feature, and they do calculate, within limits. Each field can show a calculation at the bottom, and for number fields the list is genuinely useful: Field type Calculations available Number Sum, Average, Min, Max, Count values, Count unique values, Count empty, Percent empty Everything else Count values, Count unique values, Count empty, Percent empty The calculation can be saved as part of a view, so the total is there for the next reader rather than something each person switches on. Worth knowing before you plan around them: databases are not available in the Atlassian G

The choice is usually made by whoever draws the first diagram, and then everybody lives with it for years. It is worth five minutes of thought, and the deciding question is not which tool is best but who will edit this thing next. Short answer. A visual editor such as draw.io for diagrams that non-engineers maintain. Mermaid or PlantUML when the diagram belongs with the code and should be reviewed like code. An attached SVG when the picture comes from a design tool and you need it to look exactly right. A screenshot when the diagram will genuinely never change again. The four options A diagramming app inside Confluence draw.io is the common choice, and it is free for small teams. The diagram is created and edited inside the page, links on shapes work, and anyone who can use a mouse can maintain it. This is the default answer for architecture maps, process flows and floor plans that live in the documentation and get corrected by whoever notices the mistake. The cost is lock-in of a mild kind: the diagram lives in the app's format, and moving to something else later means exporting and redrawing. Mermaid or PlantUML: diagrams as text Here the diagram is source code — a few lines describing nodes and arrows, rendered into a picture. The appeal is real: text goes into version control, diffs are readable, and a diagram can be generated by a script from the system it describes. Two things to know before choosing this. Confluence Cloud does not render Mermaid natively, so you need an app for it, and several of them exist including free ones. And the editing audience narrows sharply: a technical writer will not touch a diagram that has to be edited as syntax, so the diagram becomes the property of the engineers, whether you intended that or not. An SVG made somewhere else The diagram comes from Figma, Illustrator, Inkscape, Visio or an architecture tool, and lands on the page as an attachment. It looks exactly as designed, which is why people do it. The catch is documented