I agree that Fibery is a much simpler tool to configure and set up than both Notion and Coda. One of the great features are the easy-to-set up relations between entities.
You guys have great views as well with your “connections” features between many-to-many relations:
I was remarking that in Notion, the best way to duplicate this view is with an embedded db. There are a lot of benefits to that view. However, those are not related entities. So I thought if you could give a user the option to add into connections here, where you select which fields to display from another Type:
but have these entities not automatically relate, you’d pick up this functionality. However, the default relation is of course very key. So you’d have a significant improved feature over Notion (and Coda which also only relate, but don’t show just a view - so opposite of Notion).
This would be lovely to have! Just like you can create as many views as needed to entities / types in the Smart Folders, adding a field for “Views” to add views that are not necessary directly related to the entity itself.
This would allow for (fake) “Lookup collections” that are just views filtered contextually without being read only (and other missing features the lookup collection view has).
Use case example:
Department → Projects → Tasks
If I want to see all the tasks in a board view (by assignee), the only way either make a view in a smart folder, or add another view to the “Projects” relation that will show the tasks. But this is a bit weird because the label for that relation is just “Projects”.
If we can add “View” fields to a database, then it will be able to show those views in the entity view. It would be less about the data or permissions within the view, and more about access to the view itself.
One difference is that (for some reason) in smart folders, and also in embeddable views, you can only select from the dropdown a database that is related (directly or indirectly) to the entity. But this would be nice to have that it does not need to be related. For example if I want to just see all open projects in a meeting. No need to have them related in any way, but have them in the meeting entity for us to have a look at for the meeting.
Embedding views into the rich text is not scaleable as it means it needs to be done for every department manually. And is then configurable by editors as opposed to only configures.
If I want to see all emails from all people in the company, I could use a lookup, but then I can’t create and its much less powerful.
Instead, right now I need to add a relation and add a context filter to show the emails from people from company. Then when I link a person to the newly created email, it doesnt even add the company!! This makes sense, as the filter has nothing to do with the company. But the thing is that then this Company → Emails relation isn’t and shouldn’t a true data relation. Just a view. Like a lookup.
So I guess this is questioning the whole deep context filter concept. If its a deep context filter, it should be just a view and not a schema relation.
Technically its just a more powerful lookup no? Shows the same data when configured…
It’s frustrating because I don’t want to add a relation field when a lookup is actually what I need. It’ll just be an empty field that can confuse people and clunks up the schema.
This is related to another similar need that had some conversation late last year, would be curious to get your take on this one as well and whether it’s a need of yours, too: