Individual Layouts for a node, hide fields etc

It is no problem at all to have different views (table/board/timeline/calendar) in different apps that show different fields, so that, for example, a user can open a view of Clients in the Development app (which shows the Servers column), and a different view of Clients in the Sales app (which shows the Contracts column).

However, if you mean that you want to adjust what relationship fields are shown when you open a specific single Client entity, then I’m not sure I understand how you envisage it to work.
An entity is an instance of a particular type (where a type has initially been defined in a specific app) so I’m not sure that is has any meaning in Fibery to ‘view an entity in an app’.
Although a table/board/timeline/calendar view can list many entities, when you click and open a specific entity, you’re not looking at it ‘within an app’.

Are you saying that you would want the visible/hidden fields of an entity to be dependent upon the route via which you arrived there? So if you click on an entity from within a view in the Development app, then you will see different fields than if you click on an entity from within a view in the Sales app?

If so, what would be the difference (in which fields are visible/hidden) between the view (table/board/timeline/calendar) and the entity itself?

I’m sure @AndreasHe can clarify best, but here’s what I understood their meaning to be:

I have a Type, Client, which has relationships to both Servers (Type) and Contracts (Type). If I open a given Client Entity, I will see lists of both as Related Entites. If there are many such related Entities, these lists could be long. If I am a Developer (Role), I do not care about Contracts, and if I am a Sales Person (Role) I do not care about Servers.

So what seems to be requested here is the ability to create different “templates” for viewing an Entity which show or hide different fields (including relationships). It sounds like doing this on a per-role basis might work (if you could define custom roles), but also perhaps it is desired to be on a per-user basis.

Personally I think that most of the use cases so far described here could be handled with two new features (that I would also like to have):

1: Collapsible field Groups. I don’t need them to be fully hidden, but being able to define a whole set of fields as a Group and then “roll up” (i.e. collapse) them would be really helpful for increasingly complex layouts. It would also reduce my need for more and more Types because part of the reason I define a new Type now is to reduce complexity of the Field contents in a parent Type (i.e. I move fields with some commonality into a sub-Type, but they could just as easily be in a Group).

It would be nice to have Collapse for individual Relations Entity lists, too.

2: Per-user persistent collapse state for Entity View. So if a given user collapses a given Group, the next time they view an Entity of that Type, it will still be collapsed. This would mean every user would have to manually collapse anything that was not relevant to them, but only the first time. The ability for an Admin to define view permissions for Groups would also be good, but persistent collapse state would also partially solve this, and has other benefits.

Hopefully @AndreasHe can correct me if I’m way off on what this request is :wink:


Yeah, that’s what I understood first time around but then I didn’t quite get this part:

It wasn’t entirely clear whether the use case is a role-dependent (~user-dependent?) feature, or something that depends on how/where you got to the entity from.

There can definitely be times when there is information overload for some entities, and I agree that being able hide/unhide fields (relationships or direct fields) is useful :slight_smile:

If it is a user-based feature, I was trying to elucidate whether a user needs the option to switch between multiple settings for field visibilities at different times, or if he/she is likely to be happy with the layout after it has been defined the first time. If the latter, then your #2 seems like a decent solution.

Finally, if it is a role-based feature, is it desirable that any user who is a member of the role group has the ability to change settings that will then affect every other user in the group? And what if a user is a member of multiple groups?

1 Like

Ah yes, I see what you mean, and it’s a good point. I took it to be an optional/additional idea, not the core of it. And while it seems interesting, it also seems complicated and fiddly to both implement and use. Better, I think, to simply define alternate views that either sit within a given app, folder, or promoted entity based on their layout and relation to a given App, etc., or to define alternate layouts that can perhaps be accessed as “tabs” in the single Entity View. In fact this is an idea I’ve had before, but more for general Views (Table, Board, etc.); rather than having each variation of a View be a separate item in the left menu, like ClickUp or Notion you could select different saved and named Field views and Sort options from a dropdown or similar.

I can only answer for myself, but this is where collapsible (but not hidden) Groups and Relations seems most helpful. That way you basically get the best of both worlds, you don’t need to “switch between multiple settings”, just expand the stuff you want to look at in any given moment.

Dear lord please no, hah. I’m not sure if anyone else would want that, but I definitely do not, and it sounds like a weird thing to have be possible. Defies general expectation of user experience, in my opinion, that one “peer” (group member) defines view config for all. Better to have admins able to do this, if it is possible at all to define on a Group-wide basis. I still favor the individual collapse/expand and possible persistent state of that per-user, but I could see some people wanting multiple pre-defined layouts for Entity View in a given Type.

Yep. Agree. And you’re right, when I say hidden/visible, I actually probably mean collapsed/expanded, like in Airtable :slight_smile:

1 Like

Hi Guys,

I believe you are getting onto the subject that has been frequently discussed: A way to reduce the number of fields that show when you have a plethora of Relations to a Type - to put it in more simple terms (which I hope I did!).

Here is one of the better previous convos on the subject, with @Polina_Zenevich in fact weighing in:

@Oshyan, when you mention here:

and touch on Notion, I think that is one of the biggest flaws of Notion, solved only somewhat by Fibery until there is a solution for handling unused Fields. Notion has the negative of a hugely long page when you add relations, which becomes redundant when you add a Linked Database, which in fact you need to do to get a lot of the benefit in Notion.

If Fibery could solve 1) the situation with unused Fields that must at the moment exist when you create a relation, and 2) more ability for “Collections” (that’s the proper term for the many-to-many groupings in an Entity’s details area) to behave like Subtables - for example inline edit - then there is a real benefit over Notion here. This is something that would really help me with my use of Fibery and the whole UX of your app.

And I can’t comment here without thinking of our old friend Polymorphic Relations, since their existence vastly reduces the need for so many fields. And again @Oshyan in that post, you said Conditional Fields would be helpful here. Very true, too! I have many instances when I have a dropdown that if I select one value, I’d like to have a related dropdown field that would either 1) only show up if that value is chosen, or 2) show some filtered options based on the value in the first dropdown. I believe Coda can handle the latter scenario with Formula Filters, so perhaps that’s something Fibery might get sooner than later?

Hope that’s a useful contribution guys!


Yep! And I’ll just add that I think Field Grouping and Collapsible Groups would be one step on the road to Conditional Group (and possibly field) Visibility.


Wanted to add to this as I think it’s the closest request to general “hiding fields” we have in the community.

I think we could really use some basics around this, to overview:

  • Ability to simply hide fields - good feature of Airtable and Coda. One use case I have: I’d like to show time in Status. My plan would be to have a formula field for each time the state moves across the workflow. If I have a development workflow, this is going to be 5 - 7 different states though. So I’ll need that many formula fields to calculate the time between each. I don’t want those visible by default on every Entity though. With these fields, I can then set up a nice Vizydrop report called “Time in Status” for my team.

  • More sophisticated functionality like Notion just released to customize on a per-entity basis how fields display Unlike Coda (to my knowledge), with Notion’s recent release here this past fall, you can now on an entity-level determine if a field is hidden or not, very useful. You can also across a table (Type in Fibery) determine if a field displays if it’s empty or not. Also something we could really use in Fibery given the reliance on fields and need to at times proliferate relations.


Just a quick comment about wanting a Vizydrop report to show ‘Time in Status’. Instead of using extra fields to calculate the time between each, have you thought about using the formulas available in Vizydrop reports to calculate these values instead?
That way, you don’t need the extra fields cluttering up the entity (hidden or otherwise).

Ok Chris, is that something Vizydrop can do? Look into the backend and see how much time an Entity is in a given State? If so they yes, this need would not have to have hidden formula fields to be solved obviously…

Here’s a screenshot of a report where a chart can be generated with the Y-axis showing the value of the date difference between creation date and modification date (just as an example, with dummy data):

You can do similar things with the other Report types (Table, Metric and Pie chart) depending on how you want the data presented.

Ok thanks! Don’t mean to take up your time with this as we will look at this ourselves, but one quick observation - you mention “creation date” vs. “modification”. Specifically I am looking for how long an entity is in a state in the Workflow extension. So when it moves from “in progress” to “in review”, now long is in “in review” till it next moves to “ready for testing.” The only way I could think to log that info is to use a formula field that would read the workflow for just those two states, and trigger first when the entity hits the state initially, and next when it hits the next state, and then yet another formula field to get the difference between those two times, and thus give you the total time in the State.

Hope that makes sense!

Yeah, sorry my bad.
I realise now that I had in my head a vision of your setup that was close to this and that you already had date fields for the state change, and you wanted to report on the delta between two time stamps.
Not sure why I thought that! Serves me right for posting after a long day at work :slight_smile:
Your comment about looking into the backend should have clued me in.

Anyway, yes, I guess that you need to do something on the entity side of things (either action buttons or formulas) to get at least some of the way there. Sorry!

1 Like

Chris, thanks and no apologies necessary. You deserve a medal for the work you do around here :smile:

Your solution is also useful and something we may like to have to just see how long a task has been in its current state (I believe that’s the intent). I was looking to try to keep a record of how long something is in each state, as I think you gathered. And my point is that this could be done with a range of hidden formulas fields that would be invisible, only surfaced in a Vizydrop that would access that data to create the report.

There are probably tons of other uses of hiding fields which just serve to make calculations. I know when Notion revealed their ability to hide those fields, they made a big deal out of it, and rightfully so as it’s a very useful feature. Especially with Field Proliferation a real issue to deal with in Fibery for the moment.

Thanks again!

I just happened to be revisiting this discussion, and I realised that the CFD charts that are now available in reports would somewhat satisfy the need to

We’ve had a need for this too in our company, mostly with a particular Type of ours; product order.

Already we have plenty of Fields. Some Fields are utility fields for other Types or Fields (which uses them for filter/sorting/calculations), some Fields are used for all kinds of orders, and some Fields are used on most orders.

Having to create different order Types is not a suitable solution either. We have category and then a subcategory of products. The Fields would even depend on the subcategory. There’s also no way to have some sort of wildcard Field that can show links from many Types in one Field.

There are other things (e.g. specifications) we wish was a dedicated Field, but they’re only used for an order of a specific product. This means a condition is met to determine if a field is useful to show or not. Therefore most of the time they’re useless and adds to clutter, and instead we have to write them into the description field and highlight.

1 Like

I would love to create custom Entity Views for a Type, where I can:

  • limit which fields are visible
  • have more control over layout
  • insert new UI elements (e.g. Buttons, static text, images)
  • insert arbitrary Views (sorted/filtered)

Entity views would then have a dropdown to select from the views that exist for the Type.


If you insert new fields from a custom view, do you mean that these fields are only available in / associated with that view?
Or are you actually just creating fields for the type itself?
The former sounds a bit like subtypes, which has been discussed elsewhere, with pros and cons of course :slight_smile:

I was thinking more of static UI elements like text and images, or Views; I guess “fields” is the wrong nomenclature. Except for Buttons, which would belong to the Type.

The basic idea here is to expand the concept of “multiple views” to include Entity views, not just Type views (collections).

Much of this has been discussed previously and I believe many aspects you mention are planned in some form. Overall I am interested in similar capabilities long-term.

1 Like