Skip to main content

Appreciate any feedback/guidance as I work to complete my first Airtable project for myself. I have some previous experience in FileMaker (ca. 2006) and a basic understanding of relational databases but nothing professional. This is my first time using Airtable but I’m getting the hang of it. Mainly, I’d like to know your thoughts as to the way I’m organizing and what you would recommend to improve.


I am creating a way to track location and sales of limited-edition fine art prints. Each unique image is considered a “Work” and will typically be printed in three editions: small print size edition of 50, medium edition of 25, and large edition of 15, plus a certain number of proofs for each size that would also need to be serialized/tracked. The specific numbers in the editions may be sold out of order (for example, 6 of 25 might be sold before 3 of 25).


The way I have it set up so far is a table of Works, with a thumbnail and basic fields to describe the image (Title, Talent, etc.), a table of Editions that would track each print size associated with that Work, linked back to the relevant Work), and a Prints table to itemize every print from every edition (with links back to the Editions and Works tables).


Does this setup make sense?


One place I’m running into trouble: is there any way to automatically build out all Prints entries for a specific edition once the edition is created? Let’s say I specify a total of 25 medium prints in an edition, can entries 1 through 25 be automatically created? The goal would be able to show which edition numbers are still unsold/available from any given edition, so maybe a formula would be better for this?


Appreciate your help!


Hi @Brandon_Vogts - yes this set-up sounds good for what you are trying to achieve. For the automatic build out of the print entries, I’m afraid not, there isn’t a way in Airtable to do this. It could be done externally using code and the AT API, if you wanted to go down that route.


JB

Thanks, Jonathan. The research I’ve done suggests that data validation is another weak point using AT. My biggest concern is the possibility of accidentally creating a duplicate of a particular edition number. For example, if you had a specific copy 7/25 and accidentally signed and sold another print as 7/25 it would be a potential legal nightmare. So a prerequisite to a workable solution for this project would be to prevent duplicate edition numbers from being created (force unique values).

Thanks, Jonathan. The research I’ve done suggests that data validation is another weak point using AT. My biggest concern is the possibility of accidentally creating a duplicate of a particular edition number. For example, if you had a specific copy 7/25 and accidentally signed and sold another print as 7/25 it would be a potential legal nightmare. So a prerequisite to a workable solution for this project would be to prevent duplicate edition numbers from being created (force unique values).



Using an API solution (which may include tools like Zapier or Integromat), that problem could be easily alleviated, as the setup that creates the records would number them sequentially.


Another possibility that would prevent duplicate numbering is the setup I outline in this post:




With a small addition to the setup, you could use a formula to automatically create the copy number for each item in a series based on how many total records exist for that series. If there’s only one item in an edition, it would be 1/1. Adding a second item would change the first to 1/2 and the new item would become 2/2. The API would only need to create the desired number of records for each edition, with the setup logic automatically applying the proper numbers to each item.

Reply


Terms & Conditions