Can we please have the possibility to define fields that are to be available for all entities within a given app, or even all entities within the workspace 
5 Likes
@Chr1sG, great suggestion! I am really eager for “cross-Fibery” stuff to start to come through, things that would be cross-App, or something that can be used anywhere in any Entity as you suggest. Some big stuff I’m eager to see is basics around not so much fields - which don’t get me wrong I support 100% - but also more intuitive ways to see all assigned Entities via a good “Dashboard” functionality, some simplistic reports you could create at Workspace level. You and I have discussed this a bit, but my team gets hindered by having to find stuff within an App, without a central “Workspace” default area for say a Workspace-wide Whiteboard or Vizi report. I am hopeful the team is working on this, as during my testing of Targetprocess it really shines in this area, and we have the same pedigree here in Fibery!!
I digress a bit, but it’s not obvious to you mean if you’re a former TP user, as are a lot of folks here in the community. If so, would love at some point to find out what parts of TP you’d like over here in Fibery with greatest priority…
At any rate, it occured to me that it might be useful to the community to mention that you can get cross-Fibery functionality with tagging. I posted about this below when I discovered it:
Have you seen this? If you name a field in a drop-down the same in two Types, you can pick it up as an option in a Board. This is a terrific hidden feature! You cannot do this in Notion - no way to carry tags across tables.
Hope that’s useful, cheers!
1 Like
Yes indeed, and if it were possible to define fields that are to be available for all entities, then one could achieve a sort of polymorphism.
Say I create a new type (called ‘LinkAll’) and then I define a field for all types (called ‘Poly’) which is a relationship to ‘LinkAll’. Suddenly, a ‘LinkAll’ entity is capable of being connected to any entity in the app/workspace. Of course, the basic implementation of this would result in the ‘LinkAll’ entity having a large number of fields (one for each entity type) but perhaps these could be combined into a generic field (called ‘Poly’).
What a feature that would be!
1 Like
Wow, you guys are really into it 
@Chr1sG, could you please give a couple of examples of what you’re trying to achieve? We’ll brainstorm possible solutions with the team. The more specific you are (processes, fields, visualizations) — the higher chances we’ll think of something not too ugly.
OK, well one of my needs relates to monitoring/controlling the review/approval workflow, and actually, a lot of my feature requests relate to various ways that I could envisage solving it
Going back to basics, I ideally need the following:
- a complete historical record of an entity and all its changes (including by whom)
- the ability to define ‘snapshots’ corresponding to an entity being approved (including by whom)
- warning (or preventing) that an entity has been (or is about to be) changed since the most recent snapshot
I have thought about various ways of getting close to this ideal without needing too many more features, and have contemplated the following workaround:
Submit and Approval buttons [edited]
When the ‘Submit’ button is approved, the current user is recorded in an ‘Author’ field and the current date/time is recorded in a ‘Submit date’ field.
When the ‘Approval’ button is pressed, check that modification date < ‘Submit date’. If so…
- the current user is recorded in an ‘Approver’ field
- the current date/time entered into an ‘Approval date’ field
- the whole entity, with all fields included is exported (probably to some non-fibery cloud file storage or whatever)
- the ‘Author’ field is then cleared
In addition, a formula field called ‘Stage’ can be used to provide visibility on progress:
If the last modification date is < the ‘Approval date’, the item is at the approved stage.
If not, then…if the 'Author field is not empty, then the item is at the submitted stage, otherwise, the item is at the draft stage.
I believe that if I experiment with the action button scripting that I can achieve the above (although I think the export part may be a bit challenging!)
However, in order for it to be as easy as possible, it would be really nice if these extra buttons/formulas could be defined once for all entities. Otherwise there’s a bit of an overhead every time I create a new type.
Of course, as the saying goes, there’s many ways to skin a cat, and I could imagine perhaps solving this in other ways.
For example, when complete entity change history become available 
then only the snapshotting/export + warning function becomes necessary.
Or if the existing workflow extension gets some automation functionality, and dynamic https://community.fibery.io/t/entity-level-permissions/117/9 and https://community.fibery.io/t/locking-entities/911 are implemented, then I could imagine figuring something out.
Hope this is food for thought 
1 Like
Quick question, is it possible to write an action button script that will export an entity, including all fields, without specifying the fields in advance?
As a side question: I know that table export is available, but are there any plans for other sorts of export capabilities?
Another follow-up comment.
There is a bit of talk about polymorphism in other community discussions, and it dawned on me that polymorphism would be a workaround to the above problem, in that, if you want to have fields that are to be used by more than one type, then you can just create a new helper type with the fields you need and then link it polymorphically to all types that need those fields.
I realise that these fields would then only be accessible as ‘lookup from’ fields, but it’s more than half the battle won as far as I’m concerned.
1 Like
Great commentary here and wanted to tag @Oshyan as well - not sure this is the best place for what I want to add here as we have a bunch of discussion around this going on right now, in particular your use case along with mine over in this main post on the subject:
I think I also tried to lay out the subject around evolution of the “Collections” area within Entity views - which I think is one of the absolute shining stars of Fibery, also in this post:
So what I wanted to add to what you just wrote @Chr1sG is I think there is a lot of use of relations in exactly the way you just discussed in that last post. These are not quite handled with the existing “relate a Type to a Type” structure in Fibery. In particular, I often have within a Type one particular Entity that I want to relate to a whole other “child” Type. One example is in my Software Platform, I have one entire component, which is a Type as there are many components, which relates to another Type in another App. So I don’t really want that “child” Type In the other App to relate to every other of the Component “parent” type, but I have to right now. This also means that in the App “Map” feature (I’m talking about the visual that you get with connectors across your apps at the bottom left of Fibery, which in and of itself is a great feature unique to Fibery!), I will see this one “child” Type related to the entirety Component “parent” Type. If I could map this on the Whiteboard more accurately though, I would see all the Entities in this parent Type, but only the one particular Component linking to the “Child” Type, not the whole Type. Without this, I can only get what is really an inaccurate visual as only one Entity in the Type relates. I think this is a situation you are referring to that would be solved by what you are talking about?
I wanted to bring up that we have an interesting existing feature of Building boards to show a sort of Polymorphic View right now, which I think might be a good way to approach a solution to this issue. So I wonder what about implementing some of the Board view in Collections?
Boards are probably my favorite feature of Fibery. All you need is to have established relations, and you can then create a very custom view of that Entity. I have often thought that they would be more powerful if when you choose “show This type in Left Menu” in the App settings, and thus each Entity can get its own view, how great it would be if The Board would show more of the Entity, instead of just its name at the top.
This would also get basically get us the same “super feature” of Notion of the ability to have any related content display in multiple ways within a Notion Page.
I think this could be a fairly easy build technically as it doesn’t actually require infrastructure change to account for Polymorphism within the relation function, which as I understand may be a challenge. But you wind up able to get a view that actually includes many different Types, is filtered, represents true relations. Granted, you have to set up those relations, but if we had the ability to hide in other Entities unused fields, that would prevent other cards in the Type getting overwhelmed with empty fields. In essence, what would happen is you relate Types to each other, but don’t have to show those relations on within specific Entities unless you want to. And this results in a truer representation of the relations - you don’t have each and every entity forced to relate to every other one in the related Type.
Hope that’s helpful and not too overwhelming of a suggestion 
1 Like
Quick comment:
I don’t understand your suggestion about boards, sorry. As I see it currently, the ‘title’ of a board is “BOARD FOR XYZ_TYPE” so I’m not sure what you mean when asking to show ‘the whole entity info here’. Do you mean the app relationship diagram, or information about a specific entity?
With regards to the ‘hidden fields if empty’ idea, it’s certainly a nice and simple workaround to achieving a sort of polymorphism, but it’s suboptimal for some things, e.g. if you want to use table view and have a single column showing relations to multiple types.
For what it’s worth, before I came to fibery, I’d tried a lot of tools, and the one that was closest to my needs was something called ‘Binders’ (available for Android and Windows, see www.generism.com). It has loads of cool and subtle features, but the multi-user experience is basically impossible to achieve. I’d encourage @mdubakov @antoniokov @Oshyan and @B_Sp to have a look at it for inspiration.
1 Like
One of the challenges of developing a system like Fibery (or indeed Notion and other similar things) is that there can be many ways of doing something and, before they are implemented, there are many ways to even conceive of accomplishing the goals of some group of users.
What you’re suggesting here would seem to map fairly well to the way I see embedded Views working:
In particular, and as an extension to that idea, if there were a way to (optionally?) show a “loose” or “ad-hoc” relationship between an Entity and any View that embedded it (this could just be in the existing References section, but it might be beneficial to have it separated out, I’m not sure).
Looking at the above feature request, would it address your need here, and if not, what is it lacking? I ask because I think embeddable views are an extremely flexible way to solve a variety of challenges, including (potentially) this one. Whereas I don’t see a clean and obvious solution to what you’re suggesting. Although…
OK, I just had another thought. Which is a pretty radical change to how Fibery works, so probably not likely to be implemented. But… What if we had a “switch” (toggle) at the top of the Entity view that toggled between edit or “linking” mode, and view/reference mode. In Edit/Linking mode you’d see every field, relationship, etc. regardless of whether there was anything in it. While in view/reference mode you’d only see fields that had data, including relations. And perhaps you could control globally for your user account whether entities defaulted to View or Edit mode.
Hmm… Like I said, it’s a radical change, but I’m curious if there is any nugget of value in it. It’s a simple-seeming thing that could actually help address a number of other challenges outlined here in the forums… @mdubakov any thoughts?
Hey guys @Chr1sG as well, great convo here and I hope @mdubakov and team are able to get some good ideas from all this!
First to clarify, I wanted to suggest that when we have the “show Entities of this Type in the left Menu” turned on, and thereby you can create views of each individual entity, you could get a lot of expanded potential if the actual Entity in question was more visible. Right now, as I was trying to illustrate in that screenshot, you just see the name, that’s all. The Board is the one view where you can closest emulate what’s in the “Collections” embed within Entity “cards” right now, but the benefit of narrowing down with sorts, filters, etc.
So comparing with the current way “Collections” work:
- they draw from an entire Type: You can’t filter what you do relate, and you can’t limit what you can select from.
- They show up on every Entity, even if there is no relation of that Entity to any Entity in the related Type
- You will get a new Collection for each relation.
With Boards you can solve all this, in particular boards can have multiple Types that relate to an Entity
So if we simply took this existing Board functionality, and expanded what you can see from the Entity, you can get a lot closer to being able to “see” arbitrary relations within an Entity vs. currently, where you can only see the entirety of relations you set up, and each Entity must get related and show that relation in its card view.
And @Oshyan appreciate the request of Embedding in Rich Text Fields, I’ve upvoted and will give you some further feedback over there right now!
I like the idea of toggling visibility of empty fields (which seems to be what @Oshyan is describing).
It may not even be that radical or hard to implement. I know that it has been discussed before (sort of):
https://community.fibery.io/t/some-customizations-of-entity-view-hiding-unused-fields/452
In fact, I’d love it if it was combined with the 'Locking' entities request I previously made 
1 Like
For what it’s worth, I think I’m going to take a break from making a load more feature requests I can imagine that the fibery team already have plenty of stuff on their plate (inside and outside of work).
I have a gut feeling that they will deliver great features, and then it’s just up to me to work out all the cool ways I could use them. Maybe I’m too deep in the forest and can’t see the wood for the trees. I’m happy to let them show me things I never thought I needed.
The only thing I will add though is that it would be lovely to see a product roadmap, but maybe that’s too commercially sensitive. Given how much fibery is slaying the competition, I could see why the team wouldn’t want to reveal all the cool things they have lined up
2 Likes
One more thought on this, and I think it connects to the original idea of this thread (or at least the way I read it), though it’s a different use-case.
I’d like to have fields “applicable to all types” (or be able to include an already-configured field from another type into this one) for things like lists of States for addresses. If I add a bunch of options in a single select field in a given Type, those options are not available to access from any other Type/Field, as far as I know. So being able to “copy” a field+config+options from one Type to another would be great.
This also brings to mind the idea of being able to import value lists into single and multi-selects (which I guess you could do with table view import?)…
1 Like