I would argue that fields are cheap. I wouldn’t have any qualms about a user creating a personal field - say a “Priority” field with a rating.
If I, Jeremy, am a Designer in your system, and I have a personal view, “Jeremy’s Working View”, I can create a new field in that view, called, say, “JMO Priority Rating”.
That field should, as far as I can tell, be hidden in all other views, since it was not created in those views. (There may be an exception for views that currently do not hide any fields, as perhaps the underlying assumption is that a view not hiding any fields should continue to not hide any fields, even if those fields are made in other views). And if it ends up not being hidden by default in other views, that can be remedied with little effort. The field won’t affect any other views (in terms of sorting, filtering, grouping, etc) unless somebody manually chooses to have that field affect the view. Everyone else can happily go on using Airtable as normal, while completely ignoring my “JMO Priority Rating” field.
It seems very unlikely you’d have any issues with hitting the 500 fields/table limit, even when allowing for all these personal fields.
That would be my 2-cents… but perhaps you have other good reasons for not wanting people to create more fields?
It’s also worth noting that Airtable is pretty easy to experiment with. It’s usually pretty simple to undo what you just did in a non-destructive manner. And if that scares you, it’s trivially easy to make an exact replica (copy) of your base to test something out in.
I would argue that fields are cheap. I wouldn’t have any qualms about a user creating a personal field - say a “Priority” field with a rating.
If I, Jeremy, am a Designer in your system, and I have a personal view, “Jeremy’s Working View”, I can create a new field in that view, called, say, “JMO Priority Rating”.
That field should, as far as I can tell, be hidden in all other views, since it was not created in those views. (There may be an exception for views that currently do not hide any fields, as perhaps the underlying assumption is that a view not hiding any fields should continue to not hide any fields, even if those fields are made in other views). And if it ends up not being hidden by default in other views, that can be remedied with little effort. The field won’t affect any other views (in terms of sorting, filtering, grouping, etc) unless somebody manually chooses to have that field affect the view. Everyone else can happily go on using Airtable as normal, while completely ignoring my “JMO Priority Rating” field.
It seems very unlikely you’d have any issues with hitting the 500 fields/table limit, even when allowing for all these personal fields.
That would be my 2-cents… but perhaps you have other good reasons for not wanting people to create more fields?
It’s also worth noting that Airtable is pretty easy to experiment with. It’s usually pretty simple to undo what you just did in a non-destructive manner. And if that scares you, it’s trivially easy to make an exact replica (copy) of your base to test something out in.
Thanks for that input Jeremy
As we were creating our base (there were 6 of us working to set it up for our team of 20) we tried to use as few fields as possible, as to not make the main table incredibly overwhelming.
But I’ve been coming around to see your point of view. Feels like we are working with one hand behind our back being stingy with fields that only work for everyone. haha
I did try to add a column to my personal view and it DID show up on the main table. So that’s why I wondered about alternatives. Maybe since I have full access privileges anything I create would show up on the main table?? I’ll have to get an “editor” to add a column and see what happens.
"Fields are cheap." I love it!!
(it’s worth noting that we’ve only been using Airtable, as a group, for less than a week now. That’s why I’m picking more experienced brains for ideas I might not even think of!)
Thanks for that input Jeremy
As we were creating our base (there were 6 of us working to set it up for our team of 20) we tried to use as few fields as possible, as to not make the main table incredibly overwhelming.
But I’ve been coming around to see your point of view. Feels like we are working with one hand behind our back being stingy with fields that only work for everyone. haha
I did try to add a column to my personal view and it DID show up on the main table. So that’s why I wondered about alternatives. Maybe since I have full access privileges anything I create would show up on the main table?? I’ll have to get an “editor” to add a column and see what happens.
"Fields are cheap." I love it!!
(it’s worth noting that we’ve only been using Airtable, as a group, for less than a week now. That’s why I’m picking more experienced brains for ideas I might not even think of!)
Totally understandable. And that’s why I’m here offering my advice
In a quick experiment, I confirmed what I said above – if a View is currently configured to show ALL fields (none are hidden), then it will inherit newly created fields from other Views as visible, in order to retain its “I Show All Fields” status. However, if a View hides at least one field, it will inherit any newly created fields from other Views as hidden.
So, if you hide the first “personal” field created in your main View, all subsequent “personal” fields created will be inherited to that View as hidden.
Totally understandable. And that’s why I’m here offering my advice
In a quick experiment, I confirmed what I said above – if a View is currently configured to show ALL fields (none are hidden), then it will inherit newly created fields from other Views as visible, in order to retain its “I Show All Fields” status. However, if a View hides at least one field, it will inherit any newly created fields from other Views as hidden.
So, if you hide the first “personal” field created in your main View, all subsequent “personal” fields created will be inherited to that View as hidden.
awesome! I’m thinking you meant to say “it will NOT inherit any newly created fields…” Which is fantastic. Thanks again!
However, if a View hides at least one field , it will inherit any newly created fields from other Views as hidden.
awesome! I’m thinking you meant to say “it will NOT inherit any newly created fields…” Which is fantastic. Thanks again!
However, if a View hides at least one field , it will inherit any newly created fields from other Views as hidden.
I think I said what I meant to say, but perhaps it was just poorly worded:
The View will still inherit the new field (all Views in a Table ultimately have access to all fields in the Table), but it will inherit the new field in a hidden state. The field will be hidden by default.
I think I said what I meant to say, but perhaps it was just poorly worded:
The View will still inherit the new field (all Views in a Table ultimately have access to all fields in the Table), but it will inherit the new field in a hidden state. The field will be hidden by default.
GOTCHA! Thanks so much!!