Can a record import to a new table once specific criteria met?

Hi @Jordan_Sheehan - you can’t do this directly in Airtable, although if you use Zapier or similar to automate actions you might be able to achieve it.

However, a “better” solution (better in the sense of “better base design”) is to use views and filters on the same table. Because delivered and not delivered projects are essentially the same in data terms, it makes sense to keep them in the same table but have a “delivered/not delivered” status against each record. You can then create a new view showing just delivered projects and another showing undelivered. Keeping the data together makes summarising possible for both project statuses simultaneously (although appreciate this might not be a requirement of yours).

Edit: for “projects”, read “orders”!

JB

That is a good idea - my only concern is we are using this for 4 different project managers(Sales people). Each person has their own table, we wanted to have a table for our accounting so once an order has delivered(on each of the 4 tables) the record(PO) would move to the accounting table so they know to generate the final invoice and can see all the info we have on the PO. We do not need it deleted from the original table just copied over.

I am not sure if any of this makes sense or if I am using AT poorly… I am trying to get our very outdated systems some much needed updating/organization (before I got here everything was still done through paper POs with inbox and outbox on each desk)

Totally makes sense. My “purist” view is that sales people is also a good example of where to not use multiple tables, but to have a field in a single table that indicates which sales person the record is assigned to.

I would probably approach this base so that each record has a field for sales person (1 of 4) and delivered status (delivered or not). Then create as many views as you need - one for Jim, one for Jane etc - filtering as required. Then finally a view for accounting which is any sales person but only delivered.

You can add additional fields (that are visible in some views and not others) where, for example, accounting could tick a checkbox to say that it had been dealt with - so there might be two views for accounting - delivered and dealt with/delivered and not dealt with.

The good thing about AT is that is flexible enough that you can work it many ways, so if one table per sales person works for you, then go for it. However, generally, I would try to follow “good” database design principles if you can as I do find that you can do more with AT when the design is good (in this case, all things of the same type in the same place).

Not sure if this helps you but I hope so!

JB

Love this idea! It sounds like using views we can all utilize one table but see it differently per person. Then we have all we need in one place. I really appreciate your help - if I can do it correctly this will solve A LOT of problems. Thank you!

Great! Good luck with it. You’ve probably seen this, but there’s some good info on views here:

Creating views, filtering, grouping etc.

JB

Thank you @Jordan_Sheehan for posing this design challenge and @JonathanBowen for your suggested solution. As I read through the thread, I realize it presents a sensible solution for my own, separate-but-similar, design challenge: Create a table of records having a specific field value in other tables

OK, back to the drawing board… :pencil2: :straight_ruler: :triangular_ruler: :slightly_smiling_face:

If you need to move a record to another table, we’ve built this extension that allows you to do that.