--- title: Collections and Visibility description: Organize artifacts into collections and control who can see what with visibility tiers. section: guides order: 3 updated: 2026-07-15 verified: 2026-07-15 related: [reference/roles-and-permissions, getting-started/creating-an-institution, guides/importing-photos] features: [collections, asset-visibility] --- # Collections and Visibility You'll learn how collections organize your archive, how an artifact's visibility is determined, and how to restrict or publish material deliberately. ## Collections are groups, not folders A collection is an institution-controlled browsing and access group — by donor, subject, era, or exhibit. Unlike folders, **an artifact can belong to zero, one, or many collections**. Imported museum data often places the same photograph in more than one collection; Preservated preserves that structure instead of forcing a single assignment. One membership can be marked **primary**. The primary collection drives the breadcrumb on the artifact's page; it never affects visibility. An artifact in no collection at all is **uncollected**. That's a cataloging state, not an access restriction — admin lists badge these so you can triage them. ## The three visibility tiers Everything that controls access uses the same three tiers, each contained in the next: | Tier | Who can see it | | ----------- | ----------------------------------------------------------- | | **Public** | Everyone, including search engines and AI crawlers | | **Members** | Logged-in members of your institution (any role) | | **Staff** | Institution editors and admins | ("Staff" is the editors-and-admins tier — the same access level whether you see it labeled on a collection, an artifact, or a single file.) Collections have a visibility tier. Institutions have a **default artifact visibility** that applies to uncollected artifacts. Artifacts can carry an optional override. ## How an artifact's visibility is decided The rule has two steps: 1. **Derived visibility.** If the artifact belongs to collections, a viewer can see it when they can see **any** of its collections. If it's uncollected, the institution default applies. 2. **Optional override.** An artifact can carry a per-artifact visibility override, and the override **only narrows** — the viewer must pass both the derived rule and the override. :::info The override only narrows — there is deliberately **no "make public" option** (Default / Members / Staff). An override can never widen an artifact beyond what its collections or the institution default already allow, so use it for takedowns and embargoes. To *promote* a subset of a private collection, add those items to a second, public collection instead — an artifact is visible via **any** collection it belongs to. See [Common situations](#common-situations). ::: Some practical consequences: - Visitors never see which restricted collections an artifact belongs to. The **Collection** row in an artifact page's metadata list shows only collections the viewer can see. - Moving a collection from public to members hides every artifact whose only membership is that collection. - A safe workflow for new material: import into a members-only collection, clean up metadata, then switch the collection to public. ## Set visibility in the admin - **Collection visibility** — on each collection's settings page. - **Institution default** — in institution settings; applies only to uncollected artifacts. - **Per-artifact override** — in the artifact editor under "Visibility": **Default**, **Members**, or **Staff**. Default means "no override — derived from collections/institution." Hovering **Default** shows what it currently resolves to (e.g. "Currently Members — inherited from collection 'Archive'"), updating live as you change collections. ## Per-asset visibility (staff-only attachments) Visibility tiers normally apply to a whole artifact. Some material needs a finer cut — a donor-restricted photo, a conservation log, or an internal reference scan attached to an otherwise-public artifact. Preservated supports narrowing an individual attached file to **Members** or **Staff only** without touching the artifact's own visibility: the artifact stays visible, but that one file does not appear for viewers below the tier you set. This never widens access — a file can't be made more visible than the artifact it's attached to. A staff-only or members-only asset is enforced everywhere the public can reach it: it's left out of the artifact page's asset list, the download page, and the artifact's IIIF manifest; no public zoom tiles or page previews are generated for it; and it's excluded from public bulk exports. Institution editors and admins always see every attached file, with a lock badge marking the ones below public tier. ### Set an asset's visibility In the artifact editor, each attached file in the **Assets** column has a **Visibility** control with three settings: - **Inherit** (default) — the file follows the artifact's own visibility. This is why the setting is called Inherit rather than "Public": marking a file Inherit on a members-only artifact does *not* make the file public. Hovering **Inherit** shows what the file currently resolves to (e.g. "Follows the artifact — currently Members"). - **Members** — restrict this file to logged-in members, even on a public artifact. - **Staff** — restrict this file to editors and admins. Change it and save the artifact — the file's visibility is stored per artifact, so the same file can be public on one artifact and restricted on another. The same control appears in the asset detail dialog. Files that are more restricted than public show a lock badge in the editor. When you make a file more restricted, Preservated removes the public zoom tiles and preview images it had already generated; returning it to Inherit re-generates them. This happens automatically on save. The [PastPerfect import](/docs/en-US/guides/importing-photos#import-a-pastperfect-export-folder) also sets per-asset visibility automatically from PastPerfect's RESTRICTED image flag. :::note Set visibility one file at a time. A bulk "apply to several selected files at once" control isn't available yet. ::: ## Common situations A map from what you want to the tool that does it: | You want to… | Reach for | | ---------------------------------------------------------------- | --------------------------------------------------------------- | | Publish a handful of items from an otherwise-private collection | A second, **public** collection | | Hide one item everywhere, whatever its collections say | The per-artifact **override** (Members or Staff) | | Hide one *file* on an otherwise-visible item | **Per-asset visibility** (Members or Staff) | | Release newly imported material as a batch | Import into a Members/Staff collection, then switch it to Public | | Keep an item visible but stop people downloading it | **Disable public download** | ### A private collection with a few public highlights The most common setup: the bulk of a collection stays internal, but a curated handful goes online. 1. Set the main collection's visibility to **Members** or **Staff**. 2. Create a second collection — name it **Highlights** or **Featured** — and set its visibility to **Public**. 3. Add the chosen artifacts to Highlights, leaving them in the private collection as well. 4. Leave each artifact's own Visibility at **Default**. Those artifacts are now public; everything else in the collection stays private. It works because an artifact is visible through **any** collection the viewer can see — the most permissive membership wins. Keep the private collection marked **primary** if you want breadcrumbs to keep reading as the donor or subject collection. Primary affects the breadcrumb only, never access. :::warning Don't try to do this with the per-artifact override. It only narrows, so setting an item's Visibility can never lift it above what its collections allow. Adding it to a public collection is the only way to promote it. ::: ### A public item with a staff-only attachment A public photograph whose conservation report, appraisal, or donor-restricted scan must stay internal. Leave the artifact public and set that one file's **Visibility** to **Staff** in the editor's Assets column. The artifact page, download page, IIIF manifest, and public exports all omit the file, and no public zoom tiles or previews are generated for it. Staff still see it, marked with a lock badge. ### Take a single item down A rights complaint, or a donor asks you to pull one item that sits in a public collection. Set that artifact's **Visibility** override to **Staff** (or **Members**). This narrows the item regardless of which collections it belongs to, and it's reversible — set it back to **Default** to restore it. This is what the override exists for. ### Release newly imported material as a batch Import into a **Members** or **Staff** collection, clean up the metadata, then switch that collection to **Public**. Everything in it goes live together, and nothing is exposed while you're still working. ### Take a whole collection offline Set the collection's visibility to **Staff** (for a rights review, say). :::caution An artifact that also belongs to a more visible collection **stays visible** through that one. If you need a specific item hidden no matter what, use its per-artifact override rather than relying on the collection alone. ::: ## Restricting downloads without hiding the artifact Visibility controls who can *see* an artifact. To keep an artifact visible but block file downloads (for rights reasons, for example), use the **Disable public download** flag instead — see [Downloads and Sharing](/docs/en-US/guides/downloads-and-sharing). ## Related concepts - **Galleries** are personal, user-curated sets and don't affect visibility. A gallery entry can pin a specific attached file (see [Personal discovery tools](/docs/en-US/guides/public-discovery#personal-discovery-tools)), but the same per-asset visibility rules above still apply when the gallery renders: if a viewer can't see that file, the entry shows a placeholder instead of leaking it. - **Favorites** are personal bookmarks. - Member roles (who can edit, who can review submissions) are separate from visibility — see [Roles and Permissions](/docs/en-US/reference/roles-and-permissions).