Implementation of multiple entity views started today
11 Likes
Awesome!!!
I am stoked!
One of the reasons I wanted to use Fibery was for client projects + crm.
At the moment I have a Person database that has the common fields (email, phone etc.) and there are 2 relations, Tasks, Outreach-Outbox (to track contacts)
With multiple entity views will it be possible to create a client specific view where they can see Tasks from the relation but then completely hide Outreach-Outbox from the view?
The ideal scenario is that a client can see certain information and then has no awareness of other types of fields/data (budget, internal notes etc.)
I think it is not the case. Multiple Entity View is about convenience, and not permissions. If a user has access to entity, this user can fetch all fields technically, let’s say via API call.
Also in the first release any user will be able to switch Entity View. In future we may disable with some additional setting, so your use case may be possible, but it will be not strict anyway, as I mentioned before.
1 Like
BTW, it can be done right now if you will give custom access via custom access template and disable access to Outreach-Outbox database.
Got it, this is similar to how you handle the private/public roadmap and features correct?
Not really, I think you need something like this
https://the.fibery.io/@public/User_Guide/Guide/Custom-Access-Templates-240
Love to see it, even a basic version as you described for a first release will be a big UX increase for a few of us.
1 Like
Some progress, release is coming relatively soon
4 Likes
@mdubakov This is really exciting news and will make things a lot easier for teams with users who have different requirements.
I think I saw somewhere that one of the next steps might be to use state or other fields to decide which view to show. That would make this even more useful. However, while this makes things nicer for multi-user workflows, it still doesn’t address situations where depending on the current users choices, the creator wants to display different fields, unless the user refreshes the screen so they can be sent to another view. That is why, I wanted to again pitch the possibility to control some fields (or group of fields) using based on conditions:
1 Like
We are working on this problem now. Your proposed solution is to setup default Entity View in other Views. However, it is quite hard, since you may have dozens of Views.
Do you think this flow can be solved differently? For example, if it will be possible to set what Entity View is visible by default based on some field value in a database?
Imagine, in this case you can bind Entity View to some State field and show different entity view for New, Discovery, Budgeting, etc values?
For us this would work for most of the use cases. Currently a lot of views are cluttered.
Example:
- We’ve build a digital brain
- For some of the themes within that Digital Brain you only want to collect notes / tasks etc. For others you also want to write content. Currently you will also see the content view in ‘Legal’ theme, which is odd. And therefor we’ve made another (clumsy) solution, purely for the content part.
However, the biggest problem is not always that not all views are relevant.
The problem is that we also have pages where all views are relevant; but there are just too many of them. Examples:
- The contact page is really overwhelming
- The planning pages are really overwhelming
That can’t be fixed with removing data; we just need to find a way to visualize it in a different way (like in tabs or some similar option).
Is that also the idea of entity views? That a user can switch between views so that the page is less overwhelming?
Please note that Multiple Entity View features will be in Pro plan only.
Is that also the idea of entity views? That a user can switch between views so that the page is less overwhelming?
Sure, any user can switch views from the list.
Default entity view by field condition would be interesting, but most of my company’s use cases would be better suited for @Dimitri_S suggested:
For example. I manage 10+ projects at a time. Depending on what I need to do that day, I may be working on finances, contracts, schedule, tasks, etc. I have a Table View with all my projects finances. I would want to open each entity (project) from that view and it automatically go to the project’s finance view. Or if I’m updating contracts for all projects, I would be looking at my contract view and would want each entity (project) to open to my project’s contract view.
In this example, what I’m working on is not determined by the project’s state or field condition. I think this also makes Fibery more intuitive to navigate for end-users that didn’t set up the workspace (e.g. I’m looking at a finance view and so it opens up finance pages)
2 Likes
What does it mean? How you determine that it is finances table? I assume finances is not any state/field/type of project, just what you want to do with a project now?
Correct, in this example finances is not a state/field/type. It is more of a category comprised of multiple different relationships/fields for that project.
In this example, the “finance” category will have:
- Relationships: client invoices, subcontractor invoices, change orders, change packages, budget packages, etc.
- Number/Lookup/Formula fields: original contract value, approved changes, revised contract, variances, etc.
Finances is a category of relationships/fields for what I want to do with a project now, like you said.
90% of the time we travel to the entity from these aggregate “category” views. So if I’m working on the finance category, I’ll start with the views that aggregate a lot of this information together. The views tell me which project entities I need to work on today, then I will open up the entity view from there. But I can’t default the entity view based on any single “finance” field/value because immediately after this I may want to work on the “scheduling” category and open up entities from views that aggregate different scheduling relationships/fields.
TL;DR: Custom Entity Views in Fibery should extend the “personal workspace” customization purpose of Table/List/etc. Views, allowing users to set default Entity Views for specific View entry points. This would cater to different roles and tasks within a space/database, such as a “Projects” database with Entity Views for Admin, Project Manager, Worker, and Accountant. However, this could lead to the proliferation of one-off Entity Views for specific use cases, resulting in a large number of Entity Views.
How Table/List/etc. Views Are Currently Used
@mdubakov To your point about how you might have dozens of Views, yes, let’s pretend we have a “Projects” database, and let’s stick to just Table Views. What I’ve seen many times with clients using Airtable is they end up with 10+ views for each DB, looking something like this, with each View created for a specific task involving one or more people/roles.
- All Projects Table
- All Projects Table v2
- Worker Project Tasks
- Project Finances
- Projects (finishing up)
- TEMP Projects - Dimitri Testing
In essence, these Table Views are a way for users to carve out their own personal workspace. And they are (usually?) the main entry points into the Entity Views, which currently cannot be made specific to any task/role.
The Need for Custom Entity Views
If everyone in this thread is on the same page as me, I believe the idea behind custom Entity Views is to extend that “personal workspace” customization into Entity Views.
| View Name | Primary Users |
|---|---|
| All Projects Table | anyone, but mostly Admin/Project Manager |
| All Projects Table v2 | mostly Admin but soon Admin/Project Manager |
| Worker Project Tasks | mostly Worker |
| Project Finances | mostly Accountant |
| Projects (finishing up) | mixed, Project Manager/Worker |
| TEMP Projects - Dimitri Testing | only Admin |
So for this “Projects” database, I imagine you might end up needing these Entity Views: Admin, Project Manager, Worker, Accountant
The general idea is that I want to be able to “pin” or set as the default Entity View to display from a given View entry point. So something like this:
| View Entry Point | Default Entity View |
|---|---|
| All Projects Table | Project Manager |
| All Projects Table v2 | Project Manager |
| Worker Project Tasks | Worker |
| Project Finances | Accountant |
| Projects (finishing up) | Project Manager |
| TEMP Projects - Dimitri Testing | Admin |
The Potential for Proliferation of One-Off Entity Views
In reality, I would expect that users might end up wanting one-off Entity Views for specific use cases - trying to emulate an app-like experience where the Entity View is repurposed as a way to display a custom modal, and you will get ugly things like:
| View Entry Point | Default Entity View |
|---|---|
| All Projects Table | Project Manager |
| All Projects Table v2 | Project Manager v2 |
| Worker Project Tasks | Worker |
| Project Finances | Accountant |
| Projects (finishing up) | Finishing Up |
| TEMP Projects | Admin - Dimitri Testing |
So now you actually end up with all these Entity Views: Admin, Project Manager, Worker, Accountant, Finishing Up, Admin - Dimitri Testing
What is the default Entity View on new databases/table views?
You could have a default entity view (“All Fields”) that is fixed to show all fields in their default order and placement. Then when a user creates a new view, they can select the custom entity view they want to see for that view entry point.
2 Likes
Ahh, this sucks.
Thank you for detailed reply, it helps!
I see the value, but I also see some problems in this approach.
- It is hard to foresee how a user will get to Project entity. It can be search, it can be mention, etc. In this case Project View will be default (or last used). Essentially it breaks the use case. It is assumed that for Project Finances you will go to the specific view to do it, I am not sure it is the most typical case, but I have no evidence
- View configuration will be even more complex with one additional option to select Entity View (this is not so problematic, just a nuance).
I agree that multiple pathways to an entity exist. However, from a UX standpoint, at least in my opinion, it’s logical that if you have purposeful Table views, you’d want that purpose reflected in the entity viewed from there as well.
Continuing with my previous Projects DB example, perhaps allowing admins or users to set their preferred default view for a database could address this. This would handle all undefined or miscellaneous entity entry points (search, mention, direct link). Though with shared links, applying the entity view of the user who shared the link might be appropriate.
The issue remains that we currently can create unlimited, highly customized views for multiple entities. Yet when it comes to viewing individual entities, everyone must see and use the same interface.
1 Like