On this page
An art inventory template works best when each artwork has a stable ID and every move is recorded separately from its ownership and sale status. The original CSV below is ready to copy into a spreadsheet: it tracks the work, its current location, and a dated movement log without treating a gallery loan as a sale.
Copy the artwork inventory template
Create one row per unique physical work. For editions, use one artwork record for the edition and a separate record for each numbered copy; do not reuse an ID across originals, proofs, or edition copies. Keep IDs stable even when a title, location, or status changes.
artwork_id,title,year,medium,support,height_cm,width_cm,depth_cm,edition,location_id,location_name,owner,status,asking_price,currency,created_at,updated_at,notes
ART-2026-001,Blue Window,2024,oil,linen,60,45,,Unique,STUDIO-01,North studio,Artist,Available,1800,USD,2026-02-12,2026-10-01,Sample record
ART-2026-002,Low Tide,2023,screenprint,paper,30,21,,3/20,GALLERY-02,North Gallery,Artist,On loan,250,USD,2025-09-05,2026-09-14,Copy 3 of 20
ART-2026-003,Red Study,2022,acrylic,canvas,40,30,,Unique,STORAGE-01,Offsite storage,Artist,Sold,950,USD,2024-04-18,2026-08-02,Retain provenance record
These rows are synthetic examples, not an artist's real inventory. Store measurements with units, distinguish a one-of-a-kind work from an edition, and record the asking price separately from the final sale price. If you have many works, avoid putting several IDs in one cell: a row per work makes filtering and later imports easier.
Keep location, custody, and ownership distinct
AI-generated editorial concept; not a screenshot of a deployed app.
“At North Gallery” describes location or custody. It does not by itself mean the gallery owns the work. Keep owner, location, and commercial status in separate fields. A useful status set might include In studio, Available, On loan, On consignment, Reserved, and Sold; decide whether status describes availability or physical state, and avoid using one value to mean both.
For loans and consignments, add a movement table instead of overwriting the previous location:
movement_id,artwork_id,from_location,to_location,change_type,started_on,due_back,ended_on,recipient,agreement_ref,notes
MOVE-001,ART-2026-002,STUDIO-01,GALLERY-02,Loan,2026-09-14,2026-11-30,,,AGR-2026-09,Sample outbound loan
MOVE-002,ART-2026-002,GALLERY-02,STUDIO-01,Return,2026-11-30,,,Artist,AGR-2026-09,Record return; ownership stays Artist
The second line illustrates a planned return for the same sample work. When the return actually occurs, enter the actual date and set the current location back to the studio. Keep the original loan row and agreement reference. This history answers who had the work and when without implying a transfer of title.
The Joan Mitchell Foundation describes paper records, spreadsheets, artist-specific inventory databases, and custom systems as options with different resource needs. It notes that databases can support repeated data reuse, document attachments, tailored reports, and searches across descriptive fields. Use a spreadsheet when a simple searchable list is enough; consider a relational app when loan history, documents, images, and reporting need linked records. (Joan Mitchell Foundation, “Choosing an Artwork Inventory System”)
Add related records only when they solve a real task
Use the artwork table with related records for the tasks you actually manage:
artworks: stable ID, title, year, medium, dimensions, edition, owner, and status.editions: edition name, total run, and format; each copy still receives its own artwork ID.locations: studio, storage facility, gallery, or institution, with contact and address kept private.movements: artwork, origin, destination, planned date, confirmed date, and loan agreement. A planned move does not change the current location.consignments: artwork, gallery, agreement dates, commission terms, and return deadline.sales: artwork, buyer, gross price, currency, sale date, and payment reference.
The same artwork ID should join its movements, consignment, and sale records. A gallery user should see only works explicitly shared with that gallery. The artist account manages the inventory; a gallery account can update an agreed loan or consignment workflow only if the artist has granted that access. Do not expose buyer details or private storage addresses on public artwork pages.
Turn the template into a working app
For a single project, choose Atoms Cloud or connect one Supabase project; Atoms documents them as alternative backend options for a project. A connection alone does not create working persistence: the app needs to save, reload, edit, and read back records against the chosen backend. (Atoms Help Center, “Connect Supabase”)
Start with internal inventory and permission checks. After saving a sample artwork, refresh the app and confirm its row appears in the intended table. Sign in as a second, unauthorized gallery account and confirm it cannot retrieve the artist's records. Atoms connector actions and permissions vary, so review the current connector details before enabling any external action. (Atoms Help Center, “Integrations”)
Stripe is unnecessary for an inventory-only tool. If you add direct-sale checkout, link each payment to one sale record and update it only after the server confirms the payment. Handle retries without recording the same sale twice. Stripe's fulfillment guide explains payment-status checks and repeated Checkout Session handling.
For a public catalogue, publish only fields intended for visitors, such as title, medium, dimensions, and availability. Keep addresses, agreement files, buyer identity, and movement notes private. See how to turn a spreadsheet into a web app for the broader migration path, and how to build a client portal for role-based access patterns.
A practical first pass
Import a small sample with one studio work, one loan, and one sold work. Check that the ID is unique, the loan appears in movement history, and returning the loan changes location without changing owner or erasing the outbound record. Then repeat the readback as the artist and try the same query as a gallery account without permission.
As the inventory grows, add only the fields you use for a decision or report. Missing dimensions, an overdue loan, and a work available from a particular series are useful search questions. A long list of rarely completed fields adds entry work without improving the record.
Build the inventory app with Atoms
Use this brief to request an app with the template and loan history above.
Build an art inventory app for one independent artist.
Use Supabase for this project; do not connect Atoms Cloud.
Create artworks, editions, locations, consignments, sales, and movements.
Give each artwork a stable unique ID.
Store one physical work or edition copy per artwork row.
Keep owner, current location, and availability status separate.
Never infer ownership transfer from a location change.
Record outbound and return movements as separate dated rows.
Link movements, loans, sales, and consignments by artwork ID.
Artist account can create, edit, and archive inventory records.
Gallery account can read only artworks explicitly shared with it.
Gallery cannot read buyer details, private addresses, or other galleries' records.
Public catalogue shows only title, medium, dimensions, and approved availability.
Keep agreement files, movement notes, and contact data private.
Seed three synthetic works: studio available, gallery loan, and sold.
Add a sample loan movement with a later return event.
Do not add Stripe to the inventory-only version.
Add search for overdue loans and missing dimensions.
Show movement history without overwriting earlier events.
After build, create, refresh, edit, and read back each sample record.
Repeat reads as the artist and as an unauthorized gallery account.
Report any persistence or permission check that cannot be completed.
Copy the build brief and use it to create your version in Atoms.
Copy the brief, open Atoms, and start with the three sample works. Add billing only after the inventory and gallery-access checks pass.
