Yes its great for hiding “helper” fields that shouldn’t or rarely need to be edited, but because it hides it in all views of that DB its not useable in cases where you occasionally do need to see/edit the value for that entity.
I’ve though about this a lot the last few days and if there isn’t the time or resources to create something like Interface Designer for Fibery what I really want as an alternative is
- the ability to create custom entity views that let you specify which fields to show/hide and maybe their order and…
- for each Table/Board/etc view, the ability to specify what custom entity view is pre-selected when the entity view is opened
For a use case example, we are a code & no-code dev agency and we have a Client database that has a 1-to-1 relationship to a Status Check database. The main reason Status Check was created as a separate database is as a workaround to not junk up the Clients entity view with irrelevant/excessive fields. This workaround has the downside that I now need to use Lookup fields which aren’t directly editable so I’m Alt clicking a lot to update multi-select fields that are in the other DB - and something I then need to train other users to do.
I would much rather have an “All Fields” entity view that shows all fields and then a custom “Status” view that just shows certain fields related to checking/updating a clients project status and is the one that’s selected by default if view the entity from the Status Check Table view.
Because right now when we are adding a new client or updating their info we have to use the entity view so it makes sense to have all those fields at the top. But then here is what other recurring workflows look like:
- We completed discovery, so record the client budget/our estimate/etc. → open up Client entity, scroll past and ignore all the irrelevant fields, try to remember which fields need to be updated when discovery is complete
- As a project manager, do the daily status check for the client → only use the Status Check table view that’s created for this type of workflow, don’t open the entity view because its overwhelming
As a third party example, we setup some service integrations for an Airtable consulting/setup agency that strangely enough used Fibery for their CRM & project management. This client had a far more complex Fibery setup than us and their entity views were a long and hideous mess - as an outsider even after a few hours I had no idea what I was looking at and what entity fields were associated with what workflow. I later found out this client decided to migrate their workspace to Airtable - although that might not be just because of the entity views.
In summary: It shouldn’t be intimidating to open up entity views. Someone new to Fibery doing a specific workflow (ex. adding a new contact) should be able to open the entity view and easily see what they should and shouldn’t edit with minimal training.