Thanks for that. I will dig into what you are describing and check if I have understood everything (or have more q.s)
Then I will provide honest/unfiltered feedback on what your options are and what I would recommend.
Really appreciate the engagement - that’s why Fibery users are the best 
1 Like
Thank you very much! 
Some questions on the diagram you shared:
- There are various views listed, e.g. Tulip View 1, Orchid View 3, etc. What are the database sources for these views? For example, are they all Task views of one kind or another (context filtered to specific team/role) or are they visualising info from a variety of databases?
- Should I assume that the configuration of Tulip View 1 is fundamentally the same as the configuration of Orchid View 1, just with a different context applied? In other words, which views would share the same configuration, and only differ in who could see them/the contents?
- I noticed that the Lead of Orchid X and the Lead of Orchid Y cannot see Orchid View 1 and Orchid View 3 respectively. Is this a typo, since all other leads seem to be able to see the views directly underneath?
- There seems to be a wish for some cross-team view sharing, but not following any consistent logic, e.g. Lead of Orchid X can see a Calendula view, Lead of Orchid Q can see Daisy views, Lead of Orchid W can see Tulip views, and yet Lead of Orchid Y cannot see any non-Orchid views(!) Is it simply that there is no simple reasoning for why someone should see something?
- Why would the Head of Flowers team not want to (be able to) see all the views? They get to see a lot of Orchid stuff, but nothing Daisy(!)
- Database Sources: It’s a mix. We have a few separate databases, but the core of the system is one massive Master Database. Everyone looks at this same data, but each team needs their own specific “lens” (View) to make sense of it.
- View Configurations: They are not identical. Even for similar teams like the “Orchids,” the configurations differ. While three Orchid teams might share a common view, two others require slightly different filters or groupings.
- Mistake: Yes, Leads should see the views directly associated with their functional units.
- Non-linear intersections: This is the heart of the complexity. These overlaps are purely functional. For example, the Lead of Orchid X needs to track materials coming from Calendula because it’s a dependency for their specific workflow. The Lead of Orchid Q doesn’t need that at all, but they must see Daisy data. There is no “universal rule” here—it’s based on the actual business process, which is matrix-like, not strictly hierarchical.
- The Head of Flowers: The goal here isn’t to hide information for security reasons—the Head of Flowers has the right to see everything. The goal is noise reduction. They operate at a higher level of abstraction and simply don’t need 50 tactical team views cluttering their sidebar.
Please keep in mind that this is a simplification: In reality, each Orchid team has 5+ different views… Cross-Space Complexity: The Tulip team, for example, has additional views pulling from entirely different Spaces and Databases that aren’t even reflected here.
I’d like to clarify the idea to avoid any confusion with permissions .
The request is NOT to introduce view-level permissions or change the existing access model. I understand how complex and sensitive the permission system is, and this proposal is not about modifying it 
.
The goal is much simpler: to control navigation visibility in the sidebar, not data access.
It is completely fine if a user who has access to the underlying data can still open a View via a direct link. This is not about restricting access or “locking” anything — it’s about reducing noise and making the workspace more role-appropriate.
Specifically, it would be very helpful to have a simple setting on each View, such as:
- Visible in sidebar for: Everyone or Selected users or/and Selected groups (Ideally, this would reuse the existing user and group selection mechanisms already available in Fibery (similar to how we currently assign users or/and groups in fields), so there’s no need to introduce a new concept — just apply the same selection pattern to View visibility.)
This setting would only affect whether the View appears in the sidebar for a given user.
It would not :
-
restrict access to the data,
-
override Space or database permissions,
-
or introduce a new security layer.
For teams like ours (10+ teams with different roles), this would significantly reduce UI clutter and prevent users from seeing irrelevant Views, while keeping the current permission model fully intact.
Maybe it will be a lightweight, UI-level improvement without requiring any changes to the underlying architecture.
TLDR I think I underestimated the scope of your ambition for decluttering(!) and hiding/showing views using rules based on group membership might be the least worst option if we were to develop it.
Unfortunately, I don’t think it’s coming any time soon, so maybe Personal → Favorites is the way to go.
The long version …
Thanks for all the extra info.
Having looked at the diagram, and read all your comments, I can understand why you are lobbying for view-level permissions, although I don’t know if any solution that we would be able to come up with (given enough time and resources) would necessarily make view management a totally pain-free experience.
When I think about designing a schema and sidebar to suit users, I often think in terms of a Karnaugh map whereby I try and determine what are the dimensions which can vary. So a person should see something (or not) based on their membership of one or more groups. In a simple setting, the dimensions might be ‘dept’ and ‘role’, i.e. a user gets to see stuff by virtue of belonging to specific dept or having a particular role.
In your setup, it seems like the problem is way too multi-dimensional. I can’t make a rule about what a Orchid Team Lead can see, because there is no commonality between these leads (as discussed in point 3 above). It’s almost as though there needs to be a dimension for every possible user role.
Now, I understand why that might (logically) lead you to think, “well, we can flip the problem on its head, and simply control per view instead of per user” which does in fact makes sense when there are basically as many distinct roles as there are distinct views.
However, assuming we did introduce ‘granular view level access’ as you describe (even a ‘simple’ version) I think you might find that the pain of administering them (working out who to add/remove) might still make it a bit unpleasant.
Also, I would fear that us solving for your use case (‘hiding for decluttering purposes’) might result in confusion for other users, who come to us saying “I hid this view of Tasks from person X, but I just found out that they can see all the Tasks after all”.
There isn’t a universal understanding of what view hiding should imply, and we’d hate to deliver something that delights a subset of users but frustrates a different subset of users.
Plus, I also don’t know how easy or hard it would actually be from a technical point of view, even if it were ‘just a UI-level’ solution.
Having said all that though, I wonder whether you could reach a slightly different goal by developing all the necessary views in the main sidebar (maybe with spaces per team or whatever suits) and then provide some guidance/training material to help your fellow users understand how they can achieve a less cluttered sidebar through the use of favorites in the Personal sidebar section.
Also, we have just rolled out support for folders in the favourites section which might make this option a bit more appealing.
Chris, thanks a lot for the detailed and thoughtful response — really appreciate you taking the time to dig into this!
Regarding Favorites — I understand the idea, but it doesn’t quite work for our case.
Our goal is not only to highlight relevant Views for a user, but also to softly hide certain Views from them.
For example, while users may have access to the underlying data, we don’t always want them to see specific Views such as operational reports or internal performance dashboards.
So approaches based on “everything is visible, just use Favorites or Smart Folders” don’t fully solve the problem for us 
.
Your point about potential confusion — where a View is hidden but the data is still accessible — is very strong, and I completely agree this could create UX issues.
That concern actually made me rethink the idea of view-level visibility rules, and I understand why this might not be a direction worth pursuing.
Given that, I think my initial approach — using separate Spaces per functional team — is still the most rational from a visibility and clarity standpoint, even if it’s heavier to maintain.
However, I tried to think about a solution that might better align with Fibery’s current architecture and avoid introducing new permission concepts.
Ideas:
Option 1 — Reusable / mirrored Views across Spaces
Instead of hiding Views, allow the same View to be reused (or “mirrored”) across multiple Spaces.
-
A View is defined once
-
It can be added to multiple Spaces
-
Any changes to the View are reflected everywhere
This would allow us to:
-
keep Spaces clean and role-specific,
-
avoid duplicating Views,
-
and avoid introducing any new visibility or permission logic.
We already see similar concepts in Fibery (e.g. mirroring data), so this feels aligned with the existing model.
For setups like ours, this would solve ~90% of the problem.
Option 2 — Optional, opt-in sidebar visibility (workspace-level)
As a more advanced (maybe - you know better) option, there could be a workspace-level toggle (similar to how AI features are enabled/disabled ), allowing teams to opt into sidebar visibility rules.
This would make it clear that:
-
it’s an advanced feature,
-
it affects navigation only,
-
and teams consciously accept the UX trade-offs.
However, I understand this might be more complex and less broadly applicable.
Overall, I’m trying to find an approach that:
-
avoids touching the permission system,
-
keeps the UX predictable,
-
and still allows larger teams to manage sidebar complexity in a scalable way.
Option 3 — Reuse an existing View in another Space (shortcut/reference style)
Potentially the simplest and most cost-effective option: allow an existing View to be added to another Space as a shortcut/reference, without duplicating it manually.
This would allow teams to:
-
define a View once,
-
show it in multiple Spaces where it is relevant,
-
keep each Space clean and role-specific,
-
and avoid maintaining the same View separately in multiple places.
From the user’s perspective, it just looks like a normal View in that Space — but in reality it opens the same original View. (Like a “link” to View, but looks as normal View in that Space)
Well, I meant that users could learn to always go to the Personal section (and never the Workspace section) of the sidebar, where they will only see views that they have actively chosen to add as a favourite.
In other words, they need to just ignore the (cluttered) Workspace section.
Of course, you (as admin) would ideally be able to ‘push’ a view to a user’s favourite list without them needing to consciously add it.
Thanks for clarifying — I see what you mean about using Favorites as the main entry point.
However, our situation is a bit different.
The goal is not only to reduce clutter or guide users to “their” Views, but also to avoid exposing certain Views to specific teams in the first place.
Even though multiple teams share the same underlying data , some Views (for example, internal performance reports or cross-team analytics) are not intended to be visible to everyone.
So it’s not just about “ignoring the Workspace section” — ideally, those Views wouldn’t appear there for certain users at all.
At the same time, we fully understand and agree with your point that introducing view-level permissions could create confusion and complexity.
That’s why I’m trying to find a solution that:
-
doesn’t change the permission model,
-
but still allows structuring Spaces in a way where users only see the Views relevant to them.
This is what led me to the idea of using separate Spaces per team — and potentially reusing Views across Spaces instead of duplicating them.
Let me try to summarize our actual needs more clearly for us :
-
Show each user only the Views they actually work with, and reduce the noise from a large number of irrelevant Views.
-
Softly
hide certain Views from specific teams or users — even if they technically have access to the underlying data.
This is not about data security, but about not exposing certain interpretations (e.g. internal reports or cross-team performance dashboards) to everyone. -
Have a clear and understandable way (for admins) to see who sees what in the sidebar.
-
Ideally
keep this manageable from an admin perspective — not overly complex to maintain as the number of teams and Views grows.
I fully understand that View-level permissions may not be the right direction, but these are the core problems we are trying to solve.
Also, one more question — would it make sense to slightly reframe this thread?
I’m thinking about updating the title and the first message to better reflect the core idea that seems most promising now (and thank you again for your detailed responses, they really helped clarify both the problem and a more realistic direction for a solution), something like:
“Reuse an existing View in another Spaces (Like a “link” to View, but looks as normal View in that Space)”
The goal would be to make it clearer for others who might have a similar need, so they can easily understand the idea of the thread, which might help validate whether this is a broader use case.
Do you think that would be helpful, or would you prefer to keep the discussion as it is?
Also, thanks for sticking with this rather long thread — it’s an important topic for teams like ours, and I really appreciate the discussion.