A Museum Collections App: Is This an Acquisition Transaction or a Catalogued Object?

When a museum commissions a collections database, one row per delivery can be too coarse and one acquisition file per object can repeat the same evidence unnecessarily. Decide how the transaction by which material entered the collection relates to the individual objects or approved groups that staff describe. That relationship is different from an equipment checkout or a warehouse owner field.

A useful demonstration starts with a fictional donor who supplies several objects under one documented gift. Staff should be able to find the shared acquisition evidence from an object's record and see which records belong to that transaction. They must also see which material still needs cataloguing. Importing a spreadsheet should not silently declare that work complete.

Use the museum's terminology, not a generic stock model

The US National Park Service Museum Handbook provides a specific example. Its accessioning chapter describes an accession as one item or a group from one source, under one transaction type, on one date. Its cataloguing chapter describes more detailed records for individual items or groups, with identifying catalogue numbers.

These are institutional instructions in handbook pages marked 2000, not a universal current standard for every museum. In particular, the NPS chapter also treats incoming loans as accessions while explicitly distinguishing custody from ownership. Do not import the word “accessioned” into your interface as an automatic claim that the museum owns an object permanently.

Before development, have the responsible collections professional define your institution's acquisition, accession, loan and catalogue terms. Record which decisions require approval and what evidence they need. A status selected in software does not itself transfer legal title.

Link the transaction to the right descriptive records

Ask for an explicit relationship between the acquisition transaction and the relevant object or group records. The transaction carries the reviewed source, method, date and documentary references. The descriptive records carry the identity and collection-specific information needed to find and understand the material.

Keep the transaction identifier and catalogue identifier distinguishable, including in exports and printed working lists. A user should not have to infer the relationship from similar text in two unrelated number fields.

The NPS example also shows why “same person, same delivery” is not a sufficient grouping rule. Its accessioning chapter treats a purchase and a gift from the same person as separate transactions. Use the institution's approved grouping rules rather than letting an import merge everything with one source name.

Let cataloguing progress remain visible

An accepted acquisition may contain material that has not yet received its full descriptive treatment. Show that unfinished work separately from unresolved acquisition documentation. The NPS handbook explicitly identifies accessioned but uncatalogued material as a backlog needing attention.

For your app, agree who assigns cataloguing work, what counts as a reviewed record and how staff distinguish an initial description from a completed one. Do not make a nonempty title field the completion test.

Nor should every physical piece automatically become a separate catalogue record. The NPS cataloguing chapter includes group and collection-level approaches, including specific treatment of archival material. Your collections professional must choose the appropriate descriptive level; this article does not prescribe a record for every page, fragment or component.

Protect source evidence during correction and migration

A legacy import may have a known catalogue number but no reliable acquisition link. Preserve that uncertainty and give it an owner for research. Do not attach the object to a convenient gift merely to satisfy a required field.

If a link is corrected later, keep the previous relationship and explanation available to authorised staff. Document permissions separately for source files and any public catalogue view. A descriptive record being ready for internal use does not authorise publishing donor details or restricted documentation.

Test the relationship in both directions

Use fictional material to demonstrate one transaction with several descriptive records, two transaction types from the same source, an incoming loan, a catalogue backlog and a record with an unresolved historical link. Search from object to transaction and from transaction to its related records. Export the data and confirm that identifiers, links and uncertainty survive.

Bring that model to a collections web-app discussion. The deliverable is a usable acquisition-to-description relationship, not a claim that the software certifies ownership, provenance or museum accreditation.

Primary sources

NPS Museum Handbook, Part II, Chapter 2: Accessioning, pages 2:1–2:2, and Chapter 3: Cataloging, introductory requirements and pages 3:1–3:2. The proposed import, correction and acceptance controls are implementation advice, not verified features of a particular collections product.