Albums

An Album is a named collection of architectural views — a place where the workspace’s entities are arranged on diagrams that answer specific questions. Albums are how Albumi lets a landscape be seen, shared, and debated visually, rather than only read as a list of records.

Unlike a Miro board or a draw.io canvas, an Album is not a free-form drawing surface detached from your model. Everything on an Album page — every application, every integration, every data object — is a real entity in your workspace. Moving a node on the diagram changes its position on the page; adding an integration between two apps creates a real Integration record. The diagram and the model are two views of the same thing.

Three kinds of Album

Every Album falls into one of three categories. The type is set at creation and cannot change.

Live

A standalone Album you create manually to document current or target state. Lives in the workspace independently of governance — edits to its pages are direct edits to the workspace (subject to the usual role and ownership rules). Use Live albums for reference architectures, domain maps, “how it looks today” diagrams, and anything you want a stable visual record of.

Change Request

Created automatically, one-to-one with each Architecture Change Request. The Album name always mirrors the ACR name; both track together. Pages added to a CR album edit entities within the scope of that ACR — the change-request identifier is stitched to every mutation, so the diagram drafts changes that only become part of the mainline landscape when the ACR is approved and implemented.

CR albums are the drafting tool for a change: proposal and diagram combined. Once the ACR reaches Implemented, the album freezes — you see the entities as they were at approval time, a historical snapshot. Later mainline changes do not update an archived CR diagram. This matters: a CR album is a document of how things were agreed to change, not a live view.

Auto

System-generated albums that exist per-workspace for queries Albumi knows how to answer automatically. Three exist today: the lineage view (one page per data object, showing where that data flows), the integration-map view (one page per application, showing its peer integrations), and the landscape view (three pages per workspace, grouping applications by hosting, by data classification, and by business criticality, with integrations between them). Auto albums are not created by users — they appear when the underlying feature needs them.

A Page is the unit of content, not the Album

An Album is a container; the actual diagram is on a Page. One Album can hold many Pages, and different Pages in the same Album can be of different types. The distinction matters because Page type — not Album type — determines what you can and cannot do on a given surface.

A new Live album begins empty. Adding the first page is a deliberate choice: pick a type, name it, and you are taken into the editor.

Five page types

Each page type is tuned to one architectural question. Choosing the right type matters more than most other diagramming decisions: the wrong type either gives you a blank canvas when an auto-generated answer would have sufficed, or locks you out of editing when you wanted to sketch.

Manual

A blank canvas. You drag applications in from a search panel on the side and draw integrations between them by pulling from one node’s port to another’s. Labels, sticky notes, hidden edges, colour-coded lifecycle badges — all user-controlled. Best for target-state architectures, domain-scoped views, and anything where you want to pick exactly which entities are present.

Creating an integration on a Manual page opens a dialog for name, carried data objects, protocol, and middleware — the full Integration record. The integration becomes a real entity in your workspace the moment you confirm. Drawing a line is not a sketch; it is data entry.

Lineage

Auto-generated from a focus Data Object. The page centres on that data object and radiates outward to every application that produces, consumes, or stores it, with Integrations labelled by the CRUD operations they carry. Answers: where does this data live, where does it go, who touches it?

Relationships on a Lineage page are read-only — you cannot add or remove nodes and edges, because they are derived from the workspace. You can drag nodes to rearrange the layout, hide specific edges for clarity, and add sticky notes. The layout algorithm produces a default arrangement; overriding it is often worth the effort for documentation that a human will read.

IntegrationMap

Auto-generated from a focus Application. Hub-and-spoke: the focus app at the centre, all peer applications it integrates with on a ring around it, edges labelled with integration names and data objects carried. Answers: what does this application talk to, and about what?

Same editing rules as Lineage — relationships are derived, layout is user-adjustable.

WorkspaceLandscape

Auto-generated from the whole workspace. Three pages exist per workspace — Hosting (apps grouped by cloud provider), Trust Boundaries (apps grouped by data classification), and Business Criticality (apps grouped by criticality tier) — sharing the same renderer with a different classifier each. Answers: what does the entire landscape look like through this lens?

Middleware — message brokers, integration platforms, API gateways — shows up as nodes between groups: one instance per group-pair it bridges, making cross-boundary traffic explicit. Within a single group, middleware is hidden, since it is an implementation detail of that group. The same physical middleware can therefore appear once on one page and several times on another, because the group boundaries differ. Each page tells the truth from its own angle.

Same editing rules as Lineage and IntegrationMap: structure is derived, layout is user-adjustable. A per-group Auto-layout action and a workspace-wide Show middleware toggle let you tidy clusters without leaving the page.

DefineSources

A hybrid type used inside Change Requests when planning data-lineage changes. Nodes can be added and removed like a Manual page, but the page is seeded with a specific Data Object and the applications currently sourcing it; the purpose is to map which application(s) will be the System of Record going forward. Used in the context of an ACR proposing lineage or sourcing changes, not as a general-purpose page type.

Who can edit what, and when

Albums are workspace-scoped: anyone with Contributor role (or Admin) on the workspace can edit any Live or CR album. There is no per-album permission — this is deliberate, to avoid an entirely separate permissioning layer on top of the entity-level one.

Editing rules depend on page type and album state:

• Live albums are always editable by contributors, any page type.
• CR albums are editable while the ACR is Draft or Revision. In Submitted, Approved, Implemented, or any terminal state, the page switches to a view-only mode and a banner explains why.
• Viewers see every page but cannot modify anything, nor create or revoke shares.
• Auto albums are never editable in structure — only in layout.

Entity-level edits from the canvas (creating an integration, renaming an application) go through the same authorisation machinery as edits from the list views. The canvas is an alternative UI; it does not bypass rules. See Permissions & Roles for the full matrix.

Sharing a page

Any Live or CR page can be given a public, read-only share URL. Click Share in the page header; Albumi generates a 96-bit random token and returns a link shaped /s/{token}. Anyone with that link can view the page without signing in.

Shared pages are served through a separate, sanitised pipeline: interface endpoints and authentication details are stripped; data-object classification, PII, and PCI flags are hidden; workspace and change-request identifiers are replaced with opaque per-response IDs. The person on the other side of the link sees the architecture but not the security-sensitive metadata of it. The share can be revoked at any time from the same dialog, which also shows view count and last-viewed timestamp.

Shares are created by Admin or Contributor. Viewers do not have the right to open the workspace to the outside world. Tokens are public by design — there is no password protection. If the page should not be seen, do not share it; if it was shared and should stop being seen, revoke the token.

Full behaviour of shared pages — how links are constructed, what exactly gets stripped, how to use shared links in presentations — is covered in Shared pages.

Limits and what is not yet there

A few practical notes on what Albums do and do not yet do:

• No file export (PDF, PNG, SVG). The canvas is a live view and there is no export-to-file action today. If you need a static copy, screenshot the canvas or, for external stakeholders, use a share link.
• No automatic rearrangement once a layout is set. Auto pages (Lineage, IntegrationMap, WorkspaceLandscape) compute a layout once and persist it. Adding new entities to the workspace after the page is computed does not re-run the layout — you see the new nodes in default positions that you can then drag. For WorkspaceLandscape, the per-group Auto-layout action re-runs the layout on demand for a single group.
• Large workspaces degrade gracefully but notice the limit. A lineage page for a data object that touches several hundred applications is technically possible but visually unreadable. If you hit that wall, scope the underlying data object more narrowly, or use a Manual page to curate the view.
• Pages cannot be reordered after creation in the current UI. Pages appear in creation order inside an Album. Delete and recreate is the workaround; pages are cheap.