Need more than a read-only Assets table in Confluence?

[#1]

A Confluence service page might need a server inventory, an ownership view and a chart showing lifecycle status. Those views may all start with the same selection of objects from Jira Service Management Assets. Maintaining a separate query for each one means keeping several definitions aligned.

I’m the developer of Argus - Asset Macros for Confluence. I built Argus to let teams define that selection once per page, present it in different ways and update supported asset attributes directly from their documentation.

Named Filters give each page reusable asset selections. You can save a filter such as “Production servers” and use it as the source for tables, lists, charts and relationship trees on that page. Each macro references the same filter definition, so you can maintain the underlying AQL in one place.

This is particularly useful when a page serves several audiences. An operations team might need technical details, while a service owner needs ownership and lifecycle information. Both can work from the same named selection.

Saved table views handle the presentation separately. Each view can have its own columns, default sort and page size without changing the Named Filter’s query. You can therefore offer an “Operations” view and an “Ownership” view over the same asset selection, rather than creating another query just to change the layout.

Filter maintenance can also be shared deliberately. Owners and administrators can assign specific users or groups to maintain a Named Filter and its views. That gives teams a way to delegate responsibility for the page’s asset selections.

Write-back lets authorised users update JSM Assets from Confluence. If someone reviewing a maintenance plan spots an incorrect status, they can edit the supported attribute through the Argus table. The change updates the underlying Assets object using that person’s JSM permissions, and the edit is recorded in an audit log.

That keeps the correction close to the work that revealed it. The engineer can review the asset information alongside the procedure and save the change while that context is still in front of them. JSM Assets remains the source of truth.

Multi-column sorting helps readers organise the resulting view. On supported views of up to 2,000 objects, Argus can sort by up to five columns once the view is ready. For example, organise servers by environment, then application and finally patch date. Combine column filters to narrow the selection further during a maintenance review.

Named Filters and column filters serve different purposes here. The Named Filter defines a reusable selection for the page. Column filters help readers explore that selection for the task at hand.

The other macros give authors control over how much detail belongs in the document. A compact list can sit beside a procedure, selected attributes can appear within a service description, and a relationship tree can show how applications connect to databases and infrastructure. Charts provide another way to examine the selected data.

Access follows the reader. Administrators control which object schemas Argus may query, and asset reads use each person’s own JSM permissions. Sharing a Named Filter does not grant someone additional access to Assets.

Argus runs entirely on Atlassian Forge and carries the Runs on Atlassian badge.

A useful place to start is one service page or runbook: define the asset selection, create the views your team needs and enable the people with appropriate Assets permissions to make corrections from the documentation.

If you’d like to see Argus in action, get in touch to arrange a live demo. I’ll walk you through Named Filters, multi-column sorting and write-back, and we can discuss how they could fit your team’s Confluence documentation.

Try Argus - Asset Macros for Confluence on the Atlassian Marketplace.