What only works when capabilities are bundled
This is the real argument for the suite. Most of its headline features are not features of any single capability: they are aggregations over whatever you have installed.
A standalone app cannot do these, because it has nothing to aggregate.
#The integrations
This | Feeds | What you get |
|---|---|---|
Every capability | Search | The search table's columns, filters, sorts, side panels and AI prompt suggestions are the union of whatever is installed: Approval status and dates, P |
Every capability | The Capable byline panel | Typing in the byline panel queries every installed capability at once and returns each one's matches as its own collapsible section. It is also the on |
Every capability | The Capable Home dashboard | Home collects widgets from the installed capabilities and lays out Getting started, the Approval inbox and the Calendar side by side. |
Diagrams and Images | Markdown | The Markdown editor's insert menu gains "From library" items that let you drop a Capable diagram or image straight into a Markdown document and render |
Images | Macros (Formatting) | The shared image picker used by the Background, Gallery, Cards, Compare images and Banner macros gains an extra "Capable Images" source when the Image |
Approval | Publishing | With "Publish on approval" set, reaching approved automatically queues a publish carrying the approved version and the approver list, skipping the nor |
Metrics and Links | Quality | Quality reports are built from word counts owned by Metrics and link domains owned by Links, alongside Quality's own tags. In the standalone Quality a |
Diagrams, Markdown, Images, Macros, Forms, C | Sites | The static site generator ships around 90 macro exporters so Capable macros (and many third-party ones) render correctly in a published website. A mac |
Diagrams, Images, Markdown | The Capable Agent and MCP | The agent's asset verbs work for whichever capabilities expose assets; the macro catalogue and approval verbs ride the same registry. An app that does |
Every capability | The Migration wizard | Migrators are collected from every capability and every macro, then regrouped by the source vendor, so a customer migrating one vendor sees a single c |
Every capability | The shared page index | One page is read once and every capability writes into a single stored summary, which is what powers Confluence CQL filtering by Capable fie |
#The four shared foundations
One page index. A page is read once, and every capability writes into a single stored summary. That is what powers Confluence search filters.
One asset library. Diagrams, images and templates are picked from the same place by every capability that needs them.
One event pipeline. Page and blog deletion events only exist in the suite, which is why Publishing's deleted-page cleanup only runs there.
One capability registry. The byline, Home, search and the migration wizard are all built by asking the registry what is installed.
This is why moving between standalone apps and the suite is a migration. Each app has its own private library and its own page index. Content made in one does not appear in the other.
#A few things worth knowing
The standalone Quality app declares search fields for diagrams, images, markdown and link domains but ships nothing to fill them, so those columns are permanently empty there.
The standalone Search app has none of the Capable search fields, so it is limited to native Confluence search.
Sites ships around 90 macro exporters so Capable macros and many third-party ones render correctly on a published site.
#Related
The suite is the aggregation, not the bundle.
