Managing Product SKUs and Details

[Jeff_Clayton]

Hi everybody! I could use some advice.

I’d like to use Airtable to manage my company’s SKU database, but I’ve run into an issue that I can’t seem to figure out. Hopefully it’s an easy one.

I’ve created a SKU base and, within it, the following tables…

SKU_Images (with columns for SKU and a checkbox indicating whether an image exists)
SKU_Allocations (with columns for SKU and then the number available for each)
SKU_Merchandising (with columns for SKU and the stuff like product name, product price, category, subcategory, etc.)

Let’s assume those would all be updated regularly by either importing CSVs or just copying and pasting data.

All good so far.

I’ve also created a table for SKU_Marketing. Whether or not we market an item depends on whether it’s available (referencing SKU_Allocations), whether it has an image (refencing SKU_Images), and whether it matches the categories we’re promoting this week (referencing SKU_Merchandising). So my SKU_Marketing table includes columns for SKU and then a bunch of linked fields from those other tables.

Ideally, I’d like to be able to have a checkbox field in SKU_Marketing indicating which items we’ll be promoting. But what would happen if a bunch of SKUs needed to be added to the tables mid-week? They could just be pasted into SKU_Images, SKU_Allocations, or SKU_Merchandising without causing any major issues, but if they’re randomly distributed throughout the list, and I pasted the list into SKU_Marketing, it would cause the data I’ve manually entered there (like the “we’re promoting this item” checkbox) to now be associated with the wrong SKUs, correct?

Is there a way to prevent this? Or a better way to configure this scenario?

[Ben_Young1]

Hey @Jeff_Clayton! Welcome in!

You shouldn’t have any issues with adding new data to your tables.

Regarding your specific concern about the addition of new records changing the values of your existing records:

There are two ways to do it safely.
The first way is to copy and paste it. I presume this is the method you were going to use use.
The second way is to use the CSV importer app.

If you can get your data in a CSV, then you’ll easily be able to toss in a CSV and map the CSV fields to your Airtable fields.

(Had to blur out fields due to PII)

All you have to pay attention to is which field Airtable will use in order to check for existing records.
In my case, it’s the order number, but in your case, it will probably be the SKU.

You can see on the bottom left of the screenshot that Airtable will update records with new data, and create new records if there are no matches found.

Additionally, you can leave out fields to update by opting to not have a field from the CSV mapped to a field in your table.

Please let me know if you have any questions or concerns about it and I’d be happy to answer any additional concerns!

[Jeff_Clayton]

I think this is exactly what I needed.

I had been thinking in terms of copying and pasting – and hadn’t even considered that the CSV Import app might do what I was looking for.

Thanks for pointing me in the right direction! I really appreciate it!

[Andy_Lin1]

Quick question: is there a reason why SKU_Images is its own table and not part of the main “SKU” table? Is it because a single image may contain multiple SKUs?

[Jeff_Clayton]

This entire process is still somewhat hypothetical, but I set things up that way because that data will come from one team, while the allocations data will come from another, and the merchandising data will come from yet another.

I envisioned each team generating their own CSV and importing it on their own schedule, without any possible impact on any other teams or tables.

Are there any downsides to keeping the data separate like this (aside from pricing)?

[Andy_Lin1]

Ah, that’s an excellent point about having separate teams that I hadn’t thought about. There are no show-stopping downsides, aside from possibly having some duplicate data across the three tables and not being able to see all the data at once (without a lot of lookup fields, which would also require a field in each label to link the records by SKU).