Ability to copy colunm to new tab

Why do you want to do that? What do you want to achieve? Seems like you need to go in other direction.

So that the two tabs have the exact same data in the drop down. We produce things in our local office and have a tab for that, and then we also have a team onsite that produces things onsite. We keep track of the local production and onsite production in separate tabs. If I want to make the one tab have all the same dropdowns as the other I have to manually fill in all the “single select” or “multiple select” options. As you can see with this particular column, I have to go in and manually type the info for 14 different options and make sure the colors all match. It would be a great time savings if I could just copy that tab with all the options already within, in to another tab. Hope this helps.

If you’re simply trying to transfer the options from one single-select field to another, try this:

1. In the table where you want the new field to be, create a single-line text field.


2. Return to the single-select field you want as the source for the options. Select the topmost cell (although I suspect any cell will do), and press Ctrl-C to copy the cell’s value.


3. Select the topmost cell (in this case, I believe it does have to be the cell in row 1) of the newly created text field, and press Ctrl-V to paste the copied value.


4. Airtable will paste the value of the copied cell into the target cell; more importantly, it will also convert the single-line text field to a single-select and populate the select options with those of the original table.


5. Correct the value of or clear the pasted cell, if necessary.

I’ve said ‘single-select’ throughout, but the process also works with multi-select fields.

If that wasn’t what you were trying to accomplish, let me know and I’ll whack away at it again…

I understand how to copy and paste, however, the more options we add, the more cumbersome this process becomes and again is time consuming. If I could copy the tab and data within in one go, that would just make it easier.

Every Table (tab) should contain records about the same type of elements, of the same Entity. The Things you produce are the same in both Tables, and that’s why you should have them in the same Things table. You won’t have this dropdown problem and you could separate the location of the Things (office and onsite) with corresponding Views and Filters, adding a new Single-Select field.

I agree with you but I also think you can have 2 different tables, serving different purposes but working together by being complementary… Each table answering specific questions about the “same thing”…

In one of my base, I’ve got a Spending table simply to see where my money is going, when, what for etc… and I’ve got a Products table which is kind of an inventory… (the next step, is to transform it in a “tracker” of my spending habits so I can anticipate and know when I’ll need to buy X or Y products)

Both of them are linked together and contain the same Category single select field which I add just to get more visual.

Both of them have different views/sorting/filtering each one of them answering a specific question I may be confronted in a near futur.

I first tried to build those 2 tables in one, but quite frankly I just didn’t like it… There were info, I didn’t need on the spending part and conversely.

So I separated the 2.

It might not be the best or ideal way but it’s a way that works for me and maybe other Airtable users :winking_face: .

Getting back to the @W_Vann_Hall “duplicate” single select field workaround (which could have helped me with the Category field in those 2 tables), I tried it last night and as always, I want to say, it’s working great :grinning_face_with_smiling_eyes: :thumbs_up:

That’s what Views are for. Are you using them? I think if you start using them you will love 'em.

When records in 2 Tables has the same shared attribute, and you want it to be reusable, the best way is to transform that into a new Table, so you will have an unique list of that attribute values. Of course you lose the coloring thing of the SingleSelect interface, but I think the losing worth the winnings. Maybe in the future Airtable adds a native feature of colored Records.

Again, you can hide what you don’t need in the Views.

If you separate the same type of elements into 2 separated Tables, you will end having a lot of problems, small like this, and other bigger ones you can’t imagine now. Logic is that hard :grinning_face_with_sweat:

Imagine any large company, like Apple, having the Customers list separated by country in several Tables, and having to repeat EVERY SINGLE attribute, ¡and its values!, in all those tables: genre (male, female), age (18,19,….), etc.

Please re-read my earlier reply more closely: It’s not talking about copy-and-pasting data; it’s talking about duplicating all of a field’s select options, including colors. Isn’t that what you are trying to do, or am I completing misreading your request?

Once again you’re right :winking_face: … I’m “getting there” (maybe a little too much, I must say, because some of my bases/tables are still “drafts” so I create more views than I really need, but I’m working on that :winking_face: ) with the views/filtering/sorting and I really do love them because there a very efficient way to see the datas :winking_face:

I might not expressed myself clearly on that because I really do agree with you again…

I create this “duplicate” Category field for visual purpose only, kind of like you said, to work around the absence of a native Airtable coloring records feature which I know, has already been requested.

I would have created a [Category] table if and only if, I needed to re-use them elsewhere in my base, but as far as it actually goes, I don’t, so it’s an “exception” which works for me :winking_face: .

I’m not against merging those 2 tables in the futur, I just “don’t see it” right now.

I must admit, I’ve found a quick easy solution (for a question of time) to something that would have required a little more thinking. :grinning_face_with_sweat:

And I do agree with you again :winking_face: , especially on the problems that can occur with redundancy of datas and logic part !

But lol, in my “defense”, this field really is an exception and fortunately it’s a personal base :winking_face: .

(I do prefer experiment and make mistakes on a personal one than on something I need for work :winking_face: )

Anyway, I want to thank you for this exchange of “point of view” because I’m learning to use Airtable “on the job” (at least, that’s why I’m here) and I will keep this my mind when the time comes for me to go from a probably messy base that works solely for me to a clean one that would work for everybody in my family :winking_face: .

That said (sorry for the incursion :roll_eyes: ), I don’t know know how the base of @Jasmine_Ruth looks like, but I can say that the trick of @W_Vann_Hall to “duplicate” a single select field, with colors etc… do work :grinning_face_with_smiling_eyes: !

Good trick! But, it populates all the values or only the values included in the copied cell?

Unrelated, but how do you get those colors? Mine are all really pale.

The extra colors are available to “Pro” tier workspaces (paid tier).

Thank you. Seems odd you have to pay to the second level to get more colors!

All values. I tried to show that in the GIF, but I’m still trying to learn licecap, and didn’t make my capture window large enough to show the entire configured list.

Something to keep in mind is that this transfer doesn’t only work between tables in the same base, but also works from one base to another. (To double-check, I just successfully transferred 211 single-select options and colors from a base someone sent me for advice to my ‘scratch’ base I use to test individual formulas and processes.)

I can’t take credit for that trick: It’s actually documented in the Airtable help center. (Although it does seem to bury the lede a bit.) I should also note the trick works with any field type, not just single- and multi-selects — and, as I noted in my previous reply, but which is not explicitly stated in the support article, you can transfer the field settings from base to base, and not jst from table to table within a base.

Learning, how to use Airtable, well, there are so many things to read, swallow, comprehend and put in motion/practice/exercise/experiment (even here, in the community) that I’m always very grateful when someone can point out a tip, even it’s an official one, already documented :winking_face: .

Thanks, for passing the word, in that case :winking_face: !

I’m pretty it will save me quite some time in the futur ! :grinning_face_with_smiling_eyes:

Thanks, this is a good work around.

Well, strictly speaking, it’s not a workaround: It’s the exact functionality you asked for, already nestled in Airtable — and how often does that happen? I’d say it’s cause to celebrate! :winking_face: