I was wondering if there was a way to transfer one row of information from one spreadsheet to another. For example, we have a spreadsheet titled Fosters that has a list of our fosters and it links to our Cat spreadsheet so we can see who is fostering what cat. If a foster then decides to adopt that cat, is there a function that would allow us to check a box or something that would move the person and their information from the Foster spreadsheet to the Adopter spreadsheet?
Page 1 / 1
Is there a reason you can’t use one table to store both Fosters and Adopters in table, and use a View to show one “classification” at a time?
Is there a reason you can’t use one table to store both Fosters and Adopters in table, and use a View to show one “classification” at a time?
Both the fosters and adopters are very long lists. And the fosters are already broken up into different groups. It will just be quicker and more simple to view if they are on different sheets.
Both the fosters and adopters are very long lists. And the fosters are already broken up into different groups. It will just be quicker and more simple to view if they are on different sheets.
I would also like to have an answer to Janae’s question. I have the same issue. Please help. Thanks!
@Janae_Young and @Valerie_Ericson the answer to this question 9 times out of 10 is “don’t use two tables, use one table with two filtered views.” It doesn’t sound like you need two tables unless the answer to any of the following questions is “yes”:
- Would the combined list of both foster and adoption records exceed your max records-per-table allotment of your Airtable plan? (I believe free accounts can have 1,200 records per table)
- Can people adopt the cat without fostering it first?
- Do you need to store considerably more information (5+ fields) for adoption records not included in foster records?
If you absolutely must use two tables: Airtable does not have functionality that will move a record from Table A to to Table B without the use of a third-party integration (Zapier or Integromat) or using the scripting block (the scripting block is free until September, and then will require a pro account). Without either of those options you’d have to manually make a new record in Table B and either: delete the original record from Table A, or link the original record from Table A to the new record in Table B.
For @Janae_Young specifically, it sounds like the following table setup may work for you: wPeople], oAdoption Records], iFoster Records], tCats]. When a person fosters a cat, you’d make a record in the aFoster Records] table linking the bperson] to the [cat]. If someone adopts a cat, you’d do the same thing in the sAdoption Records] table. Since personal information about each person would be stored in the People] table, related information would be carried over to the adoption/foster table records without redundancy.
@Kamille_Parks, we do have people adopt cats without ever fostering for us. And fosters come and go, so we have many fosters broken down into currently available, currently fostering, old fosters, not currently available, etc. So we would like to separate the fosters and adopters spreadsheets.
I will suggest using a “People” spreadsheet and/or look into those third-party integrations.
Thank you.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.