We are currently building our workspace and facing a challenge regarding Space organization.
Currently, when a User Group has access to a Space (even minimum without any database access), they see all Views in the sidebar by default. This creates significant clutter.
For example, our Designers team see empty all Views if they don’t have access to any base. Or they can see views that meant only for the Producers team (and vice versa), even if they don’t need it (and if you have big amount of teams and roles in one department - it is a problem).
The Proposal: The ability to show/hide specific Views for specific User Groups.
This would allow us to:
Maintain a “Single Source of Truth” within one Space.
Keep the interface clean and relevant for each role (Architects, Designers, Producers).
Here is simple (not full structure of department without all groups and subteams). Also it is critical to have one database for huge amount of task (it will be ultra ineffective to divide databases for each team)
Also, if we have different type of Architects (with different roles (access to data) in company/ department) - now we can’t have Architets team with acces only for specific databases. (Lead Architect has access to all info, and his team members can manage only specific databases and their views).
Clarification on the core issue: To be clear, our primary goal is not just using Views as a security gate for the database. The main issue is UI noise and cognitive load.
We want to ensure that “neighboring” teams don’t see each other’s views setups. For instance:
Designers don’t need to see the complex analytical Views used by Leads.
Producers shouldn’t have their sidebar cluttered with specific Architect workflows.
Currently, everyone sees everything, which makes the sidebar messy and hard to navigate. We need the ability to hide these Views simply to keep the workspace clean and relevant for each specific role.
You could try using Smart Folders and views within the smart folders.
Thsn filter where Team Members Contains me.
It has some quirks, and the permission of the views then depends on read and edit permission of the Team entity, but I’m curious if would work out. I haven’t don’t this yet, but I this is a valid use case for it.
Thank you for the suggestion! But maybe I am wrong but Smart Folders definitely help with horizontal organization, but they don’t solve the core issue of UI clutter.
Even if a View is inside a Smart Folder, or if it’s a ‘loose’ View in the Space, it remains visible to everyone who has access to that Space. For example, a Designer will still see a View meant for the Head Lead. Even if that View is empty (because the Designer lacks database permissions), the View title still exists in the sidebar.
Our main goal is to hide the UI elements (Views) themselves based on User Groups, so people only see the tools relevant to their specific role.
Furthermore, splitting databases into different Spaces doesn’t solve the issue either. To show data from one Space in another (e.g., via Relations or Lookups), we must grant users access to the ‘source’ Space. As a result, they immediately see all the Views in that Space’s sidebar. This creates a loop
To summarize the core issue: currently, granting even the most minimal access to a Space automatically makes every View within that Space visible in the sidebar. Even if a user has zero access to any of the underlying databases, they are still forced to see a sidebar cluttered with empty Views (all views). This creates a confusing experience where the UI doesn’t reflect the user’s actual permissions or needs.
Create a Database in Main Space. Do not give anyone any general access to this Space itself. Grant access specifically in the Database settings instead.
Create a separate Space for each team, sub-team, lead, lead teams and Head — and add their specific Views for the database from the Main Space there.
This creates many extra Spaces, but it allows to solve the problem of huge amount of unnecessary and empty Views for each team.
We’ve been building out our system for the team for some time now, and after working with it practically, we are convinced once again that View-level visibility control for Views would be an incredibly useful feature.
As we continue to structure our workflows, the need to reduce UI clutter for different roles becomes more and more evident. Having the ability to show only relevant tools to specific groups would significantly improve the daily experience for our team members.
Just wanted to reiterate this request based on our ongoing experience.
Yes, exactly — it’s about the visibility of the Views themselves, not the underlying data permissions.
The goal is to reduce cognitive load. When a large department shares one big database, each team only cares about specific subsets of records. We don’t want to overwhelm employees with dozens of Views they don’t need (even if the data itself isn’t restricted for them).
Our current situation (see the screenshot for a simplified structure - our teams have sub-teams and so on):
We create specific Views tailored for each team.
To hide irrelevant Views from others, we are forced to create separate Spaces for every team or role (e.g., a Space for the Video Team, another for the Head of Dept).
This “workaround” creates new problems: if we want everyone to see an ‘All Tasks’ View, we either have to manually recreate it in every single Space or create yet another Space just for that one View. If we need to change a filter in ‘All Tasks’, we have to go through every Space and update it manually.
It gets even messier if a View is needed for, say, 3 teams out of 5—that requires even more redundant Spaces.
Possible implementation ideas:
View Visibility Permissions: Allow to set visibility for a specific View (e.g., ‘Tasks for Video Team’ is only visible to the ‘Video’ User Group). [ More desirable ]
View Instances (Mirroring): Allow to add a View to a Space as a ‘Link’ or ‘Instance’ of a Master View. If the Master View is updated, all instances are mirrored. [ Less desirable , but ok ]
This would allow us to keep a clean, role-based sidebar without the overhead of managing dozens of satellite Spaces."
Additionally, there are cases where team members do have access to the database itself, but it’s still undesirable for them to see certain Views—like high-level statistics or department-wide analytics. It’s not necessarily about blocking the data (permissions), but about keeping the workspace focused and ensuring that employees only see the tools meant for their specific role, rather than management-level summaries.
Just to clarify: the structure in the attached screenshot is a very very rough, simplified approximation—not our actual department setup—but it helps illustrate the logic we are trying to achieve.
To highlight how maybe problematic the current setup is:
Right now, even if I give a user zero access to the databases within a Space and the most minimal access to this Space, they are still forced to see the titles of every single View (for them it will be empty) in the sidebar.
They see the names of tools they can’t actually use.
Your mockup looks a lot like a smart folder.
I noticed that earlier you wrote,
but you could add filters (‘team members contains me’) to the smart folder configuration so that e.g. members of the video team only see the video team folder, etc.
We actually explored the Smart Folder approach with your support team , but it doesn’t really solve the problem for a large organization.
Here is why it’s not a viable solution for us:
Administrative Overhead: When you have over 10 different teams and dozens of specialized Views, setting up and maintaining complex filters (‘Team members contains me’) for every single folder becomes an architect’s nightmare.
Messy Structure: It still doesn’t feel like a clean, native UI. You end up with a ‘fragile’ setup where one small change in team structure can break the visibility for everyone.
The “Empty Sidebar” Problem: Even with Smart Folders, the logic remains the same—we are trying to ‘hide’ things that shouldn’t be there in the first place.
For a workspace Architect, managing 10+ satellite spaces or 10+ complex smart-folder filters is much more difficult than simply having a ‘Visible to: [User Group]’ toggle on the View itself.
You shouldn’t need to set it up multiple times. It is a filter setting you configure once for the whole smart folder.
This is exactly the problem that smart folders are designed to address. They should have a one-time configuration, and then they adapt to whatever changes you make along the way.
I don’t understand what you are describing.
If you have a single smart folder (maybe in the default space, i.e. at the top level) with a filter configured, users will only see one or two folders within it.
I see no need to manage multiple spaces or multiple filters.
Maybe we’re misunderstanding each other. I’d be happy to hop into your space (with your permission) or you could share (some parts) of the workspace as a template and we could mock up a solution.
I appreciate the detailed explanation about Smart Folders. I actually know how to set them up that way, but to be honest, I simply don’t want to go down that path.
In my view (which might be subjective or less professional), using Smart Folders for this simple purpose feels like an over-engineered and bulky system. With 10+ teams and many databases (and several Spaces with different leves for different information), relying on deep nesting and folder filters feels like a loss of control—it starts to look like disorder rather than a clean workspace.
It is much simpler and more intuitive for an average user to have straightforward ‘View-level visibility’ settings, similar to how we manage data access. For us, a simple toggle is far more elegant than building a complex hierarchy of folders just to hide an empty/unnecessary views.
Just a note: even with our understanding of Smart Folders, we have intentionally chosen to go the route of creating separate Spaces for each functional unit. Yes, it’s more time-consuming to set up, but it gives us a level of control that we can actually manage: we know exactly who has access to what and what exactly each user sees.
For our team’s model, this clarity is worth the extra manual work, even if it’s not the most automated way to do it. It just feels safer and more predictable for our current scale.
Still, I’m very grateful for the discussion and your willingness to help!
I obviously don’t know your setup in detail, but I’m not sure why you would want to use ‘deep nesting’. I would have thought that you could solve it with a single level smart folder.
Also, I thought the focus was on sidebar clutter, and not on strict access to data, so I don’t think the number of spaces/databases should come into it.
I would also add that, given how complicated data permissions can be to configure, I honestly think that view level permissions would not end up being
but then to be honest, we don’t have plans to work on it any time soon, so I don’t know if my fears would be founded
To be clear, I am engaging to try and ensure we nail down the pain points you are feeling, not because I want to convince you that I am right and you are wrong
I really appreciate the deep dive and your honesty regarding the roadmap. It helps us plan our internal processes better.
To be honest, I still don’t quite trust the Smart Folder approach for our needs. Even if it can be done that way, it’s a matter of transparency and trust: I want to see, in a very simple and direct form, exactly which reporting is visible to whom, even when everyone has access to the underlying data. Visibility is simply too critical for us to rely on a tool that we don’t trust and that isn’t fully transparent to us.
Fibery is already a powerful but complex tool. My suggestion to have ‘View-level visibility’ is about simplifying the interface. Right now, the ‘pain’ of managing multiple Spaces is still easier for us to swallow than the feeling of losing clear control within a folder structure.
I understand this isn’t a priority for you right now, but I hope my feedback serves as a case for simplifying the UI in the future.
I’ve taken an honest second look at using Smart Folders for our setup . I’ve also drawn a more detailed map of our department (not full), including cross-functional overlaps (not all - blue teams are not connected and we have more) and hierarchy levels (I’ve simplified some team names and views for this public discussion, but the logic is now much more accurate [Views for all not included + simple local views not included in proper count ] ).
I want to be practical and honest: if you look at these points and still believe Smart Folders are the simplest way to go, I’m willing to keep digging . But if you agree that this will only get more complicated as we scale, I’ll return to our Separate Spaces approach.
Here are the specific blockers we’ve found with the Smart Folder logic:
Cross-functional visibility without “Membership”: We have many cases where people need to see a specific View of another team without being a member of that team’s group. Smart Folders usually rely on a “Member contains Me” filter, and adding “non-members” just for visibility creates a mess of overlapping rules that go beyond simple sub-teams. (and this people’s role not a parent role for the team - they are side teams in Hierarchy).
Lack of Mirroring granularity: Current mirroring is “all-or-nothing.” It propagates views across the entire database level, including all nested entities (and even up the hierarchy). We can’t precisely say: “Mirror this specific View to Team A, but not to Team B,” even if they share the same database.
No “Drag-and-Drop” for Views: Unlike Spaces, where we can easily move or copy views, setting them up in Smart Folders feels like a manual “workaround.” We can’t simply pull a finished View from one Space into a Smart Folder entity.
Matrix Complexity: Managing point-to-point visibility (showing a View to User A but hiding it from User B within the same context) requires extremely complex filter logic. It feels like we are coding the UI rather than just managing it.
The “All-or-Nothing” Sidebar for Leads: If I add a Lead to a Team to show them just one specific reporting View (from teams Views), their sidebar is immediately cluttered with all 10 views mirrored/created to that team. We need a way to show a single tool, not the whole toolbox.
Transparency and Auditability: We lack a “single source of truth” for permissions. When management asks, “Who exactly can see this report?”, we can’t show them a simple list. We have to explain a web of Smart Folder filters, entity relations, and mirroring settings.
]
, but it doesn’t really solve the problem for a large organization.
It just feels safer and more predictable for our current scale.
. I’ve also drawn a more detailed map of our department (not full), including cross-functional overlaps (not all - blue teams are not connected and we have more) and hierarchy levels (I’ve simplified some team names and views for this public discussion, but the logic is now much more accurate [Views for all not included + simple local views not included in proper count 
] ).