Nov 23, 2023 / 🐺 New Table View, discoverable Undo actions

:wolf: New Table View

Time has come and we’re replacing all Table Views with the new… Table View (some of you knew it as a Grid View :sweat_smile:). The new Table View is a combination of Table and List ideas, so you can now create hierarchical tables, such as Projects → Tasks or Products → Features → Tasks. Today, all your tables look slightly different.

What’s new in the new Table View?

We addressed many (but not all) requests, so in the new Table View you can:

  • Display entities from several databases.
  • Create hierarchical tables based on relations.
  • Re-order rows using drag and drop (make sure you don’t have Sort enabled).
  • Pin some columns to the left and enjoy horizontal scroll.
  • Batch-select rows using mouse or Shift + Click pattern.
  • Resize columns and fit all columns to the screen size or content.
  • Sort items faster, since column header has context menu.
  • Navigate better and update fields faster.
  • Enjoy better information density, more rows are visible on a screen.
  • Spot the difference between input and calculated columns.

New Table View is far from perfect, we still have 50 open bugs :lady_beetle:, but old Table View also has 50 open bugs, so we decided to release it anyway and iterate faster based on your feedback.

I don’t like new Table View and want my old Table View back!

We are keeping old Table View for some weeks, so you can turn it on in Settings → Experimental Lab.

What’s next?

We’re going to focus on the following things to make Table View complete:

  • Enable self-relation entities in a lower level of hierarchy.
  • Implement Totals and other calculations as a bottom row.
  • Implement grouping by any field.
  • Fix all important bugs and add many small things here and there based on your feedback.

:back: Discoverable Undo actions

Our Action Toasts now support the “Undo” feature for various actions. For example, it’s allowing you to effortlessly bring back deleted items (such as entities, databases, fields or views) without opening Trash. If you undo deletion actions, you can view the restored items right from the toast, by clicking on “View”.

2023-11-23 12.18.51

:butterfly: Improvements

  • Relation Field creation is a 2-steps action now, thus it should be less confusing.
  • Discard confirmation modal is added to prevent changes from being lost. For example, imagine you just added 10 new values into a single select, forgot to save them, lost all changes, and are pulling your hair out now. No more! Fibery will warn you about changes, and you will have one more chance to keep your hair intact.
  • Templates menu items is moved to the bottom in the left menu.

:shrimp: Fixed Bugs

  • Weird borders for references in shared, read-only documents
  • Broken ‘Currency’ list in Formula pop-up
  • Add Counts of items in the left column
  • A long titles should be cut in database selectors
  • Filter by Schema is missing in Trash
  • Wrong entity unexpectedly opened when user clicks on ‘Open related entity’ button
  • ‘Could not load’ for default values when user duplicates Form view
  • Selected for milestone date field isn’t displayed in drop-down
  • Emoji popover starts to appear immediately after you type : instead of :xx

Very nice! I don’t have much hair to pull out to start, so I’m glad I’ll keep more now. :smiley:

Great! Overall I am a fan of the Grid View New Table View!

Just hope that copy-paste support is coming soon, because right now it does not work for me still.

Thanks for continuously pushing!


This is a huge and useful change. Thank you very much.

And of course not only that. Discoverable Undo actions and New Table View functions are very useful.
:zap: :zap: :zap:


Hello! Your report led me to the more in-depth investigation, and I found a bug, when you cannot update rows from different databases at once with paste. Does your copy-paste issue is related to this case, or it doesn’t work whatsoever?


Ooowww guys, this makes me so happy! Glad to see that the grid has been officially released. Thanks for your hard work. :fire::fire:

One question: Are you already aware of the fact that you can’t create a new entity in a grid/table by pressing enter. I have to click on the + to create.

1 Like

Did you try to create entity using Shift + Enter?

2023-11-23 16.14.17

1 Like

These improvements are essential for broader adoption will have transformative effects for my team’s use cases, so thank you for acknowledging them and hopefully prioritizing them ASAP!


After your message I did :sweat_smile:. Nice to be able to create an entitieit this way.

Personally, I do prefer just “Enter”. Shift + enter makes it feel less intuitive. Previously I used Notion myself and there it was always a simple center.

Awesome release :star_struck::star_struck: Thursdays are the best days.

Really nice solution for showing the description of fields, even with multiple databases :exploding_head:

Small feedback

  • We often show multiple databases with the same field name (it’s so powerful that this is possible :heart:)

  • We often then have the same description for a field

  • For us, it’s not worth it to show formulas when there is a description of the field set. Since it’s mostly clutter and use needs to scan ‘what is the actual description of the field and what is clutter’.

  • And maybe more in general: is it really needed to show the formulas? We often have really big formulas that are not relevant for non-admins.


Can’t wait :partying_face::partying_face::partying_face:


Awesome. I have been using and providing tons of feedback - grid (new table) almost exclusively. I seem to notice every week or so tiny little improvements on it!

I have a quick question that relates to this image from your video and ties in with another convo we had:

This “rows” feature is fantastic. At the same time, I have had my team copy your GUIDE structure from your own Wiki/User guide. At first, I thought I need a Guide and Sub Guide table/database - but then I noticed your “Sub Guides” had the ‘G’ of Guide. There is just one table with a many-to-many relationship.

It doesn’t seem possible to add the same table/database as multiple rows in that dropdown from your video - though I think that would be helpful an MAYBE? is not that hard?

Using your own 'G’uides as an example, you would be able have a grid (new table) that shows all the rows (meaning rows in a table not rows in configure window) associated with each guide, which is another, different, and useful way of viewing the information (though more applicable to other things) versus as “documents”/guides.

Is it possible to add many-to-many relationship table/database more than once in your amazingly helpful dropdown for rows (configure) which I use all the time???

In our user guide there is one-many relation in fact, every guide can have only one parent and it is possible to visualize it as a tree list or tree table.

Many-many relations can’t be visualized as a simple one-leaf tree, so we will not add it into Table and Grid View.

I don’t understand so here is a more specific example:

Image 01 represents the config for a view for a LIST with row Guide and sub-row User.

Can this be done with just one database rather than 2? It’s very helpful.

It would show Guides with all their (Sub) Guides indented under each and collapsible, which can be achieved with two database now.

Image 02 shows what I mean.



p.s. I’m going through Table view and noticing tons of new things. It’s really good.

Thank you, for explanation, Robert. I tried to think about such a setup for a while, and for me, it’s always tough to get it in my head.

The first problem I can see, in the case of many-to-many relation, it will be difficult to understand automatically which exact guide must be at the root level, and which one at the nested because the relation goes both ways. Probably, it will be solved if user could specify what exact relation corresponds to the “hierarchy”.

Then, as I understood from your picture, two levels will be enough for your case, but how can handle the case if other users want more?

We do our best supporting as many cases as possible, but such restrictions sometimes are needed when we don’t want to dramatically complicate the setup UI and the internal logic.

1 Like

Thank you for your reply. It’s not really about the relationship. It doesn’t have to be many-to-many. It can easily be one-to-many. It’s about the “config” of views and the selection of rows.

(And it might be under the purview of something mdubakov referred to elsewhere as table upgrades that include “self-referential,” but perhaps not).

As this #1 image below shows, I can choose the first row when configuring rows for a view as GUIDE and other databases as sub-rows - in my case I chose the USER database as a sub-row of GUIDE:


In the #2 image below I show all the databases available to choose as sub-rows under GUIDE.


I have been (trying to follow) best practices identified by mdubakov, chri1sg, and others, and so as it is now time for us to make our own wiki/user guide. I just decided to copy the structure you guys used here: Start Here: Fibery User Guide | Fibery.

At first, I had created both a GUIDE database and a SUB-GUIDE database, but noticed yours only has GUIDE and also believe, from what I’ve read and learned, that in this case 1 is better than 2 because they are doing the same thing.

I just added a sample Sub Guide database as shown in this image #3:

As such, when I now go to a view config and choose rows, see this image #4:

I can now create a view (e.g. a list or a table) where GUIDE is the first level row and SUB GUIDE is the sub-row, as shown in image #5:

The ability to combine databases and use first level rows and second level sub-rows is extremely useful.

However, while I can use SUB GUIDE database as a sub-row, I cannot use GUIDE database (itself) as a sub-row, even though I changed the relationship to one-to-many.

Why would I want to???

  1. I believe the Fibery best practices say one Guide database is more appropriate than two.
  2. Currently, I would only be able to view the Guides as a taxonomy associated with the left panel, as demonstrated by your own user guide below in image #6

Shown below in image #7 is a sample view of how it would be helpful to view these items as a List (or a Table) instead of linearly as a Wiki:

However, I can only accomplish that now if I create a second database.

I hope this helps clarify. Thanks for your time.

Now I understand better, but I have a naive question, have you tried the self-relation button
Screenshot 2023-11-23 at 18.25.38

and if the answer is yes, why doesn’t it work for your case?


OMG I did not know how to do that. It does work. Thank you!!! :innocent: :heart_eyes: :partying_face: :cowboy_hat_face:


A few things

  1. I’m not entirely sure of the value of listing the row number in Name column. To me it makes more sense to have the Public ID. Or maybe better to just leave them out? And let people include the ID column if they choose.


  1. It might be nice to be able to click the Id column to open the entity.

  2. When choosing a child entity, It should be chosen by relationship, not target table. As there might be multiple relationships to the same table for different reasons.


Hi @ihartrafimovich,

After some more testing I realised that this is only a problem in Orion. Chrome, FireFox and Safari work fine. And yes, in Orion it just doesn’t work at all even with just a single database. :frowning:


All great points!

@gregbacchus, does using filters address your #3?