Sharing a Space/DB among multiple Workspaces?

I am considering how to best use Fibery for multiple departments in a company.

I am concerned that a single Workspace will be too unwieldy and cluttered and difficult to manage/customize for each department.

However, there is definitely some data that needs to be shared across departments (clients DB, users).

Is there a possibility that Fibery could have the ability to share a Space among a number of separate Workspaces?

Or, is there a reasonably intelligent way (if not ACID) to keep DBs changes in sync across multiple Workspaces in near-real time?

1 Like

Hi, Matt!
We don’t Fibery-to-Fibery sync and are not sure when it will appear
We also have some big customers (like ~600 teammates) - they started working in different workspaces but ended up in a structured one
Permissions + Hidden spaces have to work, and your ability to structure the data and configure Fibery - I’m pretty sure will make a magic :star:

1 Like

How would this work: if there are 6 Departments in my company, and each one needs “Tasks”, but they must not be allowed access to Tasks from other departments.

This would seem to require a separate Tasks DBs in a separate Space, for each Department.

So I would have to duplicate (x6) all of the work to create and maintain these Tasks DBs, as well as any other DBs that need to be restricted to certain Departments.

Add in lots of scripts (also duplicated x6) and that sounds like a maintenance nightmare.

As long as Fibery Search can show any/all entities, the limitations imposed by views have no value for restricting access by User, so we are left with only Spaces.


I think that Fibery needs to step up its game in the way collaborative technologies are rapidly becoming decentralized now. Fibery is a monolithic app that yes has integrations, but that is the minimum to expect nowadays. The next steps is to become modular and make the community contribute modules for Fibery, as well as to support Fibery to Fibery database connections.

The current topic is about multiple departments using different Fibery Workspaces, but I think we should look ahead and see the tech trends as well as the opportunity of Fibery to align with that, instead of trying to accomodate invididual organizations only.

For the readers here who are interested in that decentralized and networked development, see this related topic where we can continue the talk about that evolution:

I would likely have arrived at this question myself in time. Did you ever get an answer? I guess I wonder if you’re the admin (or creator) and you create a view using the appropriate filters to show only the allowed tasks for a given space and make it read-only, are the viewers of that space still able to change the filter to see all global tasks?

No, that’s also our current approach.

But I didn’t realize this :face_with_spiral_eyes::arrow_down:

@antoniokov is this use case covered by the new permissions model maybe?

The current permissions model only allows granularity at the space level, so if you can see/edit one entity in a database in a space, you can see/edit every entity in all databases in that space (with a caveat about contributor level permissions which isn’t important for this discussion).
And this means you can find anything in that space via api and search.

For the upcoming permissions model, granularity will be down to the entity level (eventually including levels in between). So you can have view/edit permissions for ‘X’ and you will only be able to view/edit ‘X’ where X can be a space, a database, or an entity.
And the search/API behaviour will reflect those permissions.

If you mean, the use case in the first post of this topic “sharing a space/db among multiple workspaces” then, no, it is not part of the plans for permissions.
Workspaces are independent from each other, and we have no active plans to change that.

Thanks for the fast reply!

The sharing a space/db among multiple workspaces was not the specific use case that I have in mind.

More specific this use case

  • Is is possible that a team member can only see the tasks that he/she is assigned to
  • And no other tasks

I think that is a yes? :grin:

Yes, it’s definitely a use case that we intend to solve with the new permissions model.

1 Like

Awesome :star_struck::star_struck:

1 Like