Private or User Views and Reverting to Sticky Public Views


#1

The use of views is obviously a crucial and powerful aspect to airtable but it can very quickly get bloated, especially when a base is being shared amongst a team.

My first thought is to have “private views” or “user view”, which I think reflects airtable’s goal of creating a tool that allows users to define their own tool. Within a certain table I may want to save multiple views that are really only relevant to what I want to see, and there’s no need to a) clutter up the views list for everybody and b) allow anyone else to see or edit these views.

This would also solve some of the requests regarding granular permissions for views.

For the public views, I still think it would be great to have a way to save the settings of a view so multiple people can use the view without changing it. For instance, if there is a view that just shows all the records, if somebody on the team starts filtering things, and doesn’t remove the filters, the next person who selects that view will see all the filters. On our team, we’ve been making different views for each user, both so our personal selections don’t effect others, and so we can look and edit the same data at the same time without affecting other users views. However, it would be great to be able to “revert” to a set saved state for a specific view. I find we don’t treat each view as a static state, but a starting off point.

I know some of these issues have been discussed on the forum, but I think these types of solutions, “user views” and “revert” could solve a lot of the problems we’ve been having.

Another level of organization for the views would be to have sub-folders for views. Just something else to think about!


#2

I absolutely agree!

I would suggest “user” views and “team” views and introduce a “save view” button next to the triple-dot view menu.

And if “save view” is too many clicks for some users, the view menu could have a checkbox for “auto-save view”


#3

I view this as a key feature that is missing. A view needs to be a definable look into a table. But if the filters on a view can be changed—and aren’t reverted back to the filters that define that view—then views lose much of their utility.

I would suggest the following:

-Each view has a persistent set of filters and sorting rules.
-These persistent filters/rules are basically locked across users and sessions. They are easily visible, but changing them requires an mouse click…perhaps some sort of confirmation that changing these filters may fundamentally change the view for all users.
-On top of the persistent filters/rules are “user filters/sorting rules” that are persistent across sessions, but not across users.


Lock shared views but still enable record editing
#4

Thanks for the feedback on this! We’re definitely reading your suggestions and taking them all into consideration. Any information about how our you all/your teams use views in your use cases is very helpful for us.

Out of curiosity, roughly how many views do your tables each have right now? Five or less? More than 10? Dozens?


#5

In our main table in our primary base, 24. And we try to keep that count low… But when making a view per user, you’re pretty much stick with your user-count… And 20-40 isn’t unusual at all for a Creative/Marketing shop.


#6

Our main table has about a dozen views. Some are pretty constant, others come and go depending on whether a specific project is active. Beyond that, all the users have their own views. One of the problems, as we roll this out, is that the user views are based on the main view, but if we change the layout of the main view, say add a field in the middle somewhere, it gets added to the end of the user view.

What we would like is the ability for the filtering to be sticky and flexible. For instance, if the table has a field called “assigned to:” and one of the options is my name “DS”, I want a view that just shows jobs assigned to me. Nobody else needs to see or have access to that view. Maybe the answer is less about multiple views than about being able to save different filtering options?


#7

This is a must have! Any updates on when this feature might be available?


#8

The key concept here is “persistent”. I’ve requested in a separate thread that sorting persist.

But it looks like you’ve taken it a step further with multiple levels of sort/filtering functions. One at the view level, and the other at the user level. I like it.

One of the main benefits to AirTabe over Google Sheets is the fact that a user can sift and sort without affecting another user’s view of the underlying data. I support this request.


#9

Just bumping this thread. This is a REALLY important feature to my team, as we evaluate whether AirTable is going to work for us. Any updates?


#10

I think this would be a great feature. My team has 11 members, each one has 3 main views and than there are some views that only two members use, so my team has over 50 views :unamused:
I would like to have more views but it is too many already.

Please consider this feature :innocent:


#11

A related issue is the fact that any user can modify a View (accidentally or otherwise) and totally screw things up. For example, in our Task Management table, we are setting up views for each user, filtering records by the “Assigned To” column. If someone changes the filter in the existing View called “Susan’s Tasks” she may not even know it’s changed until someone starts asking her about tasks that are nolonger visible to her.

This is a serious danger.

Having unique views for each User would help. Having “locked” views that only Admins can edit would also help. And hidden views that only certain users/roles/groups can access would be even better, but I realize that gets into some granular permission features that are beyond the scope of this topic.


#12

If it were up to me, I’d treat Views completely differently than AirTable currently does. I’d start with every saved View being visible ONLY to the user who creates it. Then, I’d create a mechanism for sharing views with other collaborators (individually, or by role/group), and for making them “public” (visible to all users). Either way, I’d make the view editable only by the creator.


#13

I’d also suggest a “Master Data” view as outlined here: Completely Hide Fields

There needs to be an experience split between a simple/elegant presentation of the minimum number fields to “consumer” users (in our case, Designers) and a more complex, and yeah maybe ugliler, view for “admins”.

User-views, as suggested by Dan above and refined by everyone else here, would also address this, provided operational formula fields can be entirely hidden from “consumer” users/views.