We have the following situation: we work in a multi-tenant environment, developing different projects for different clients.
We would like to make some public spaces for each of them to share useful info: a user guide, a whiteboard with a user journey flow, maybe a roadmap, etc.
The problems is that we don’t want to present all of these projects bundled together as it would reek of unprofessionalism.
What we would like is for:
Client A to get their own portal / URL where they can see their stuff and nothing more
Client B to get their own portal / URL where they can see their stuff and nothing more
and so on.
Has any of you ran into this problem and if so did you come across any workarounds for it?
Since these spaces are public everyone would technically have access to all its content, but this is a perfect example where security by obscurity is more than enough.
Having something like https://the.fibery.io/@public/3245-2251-3244-8456/User-guide
with a distinct url per tenant would be perfect.
I would even be okay with a single point of entry like a document, which could point to other documents, embed views or whiteboards, etc. The problem with this workaround is that the sidebar is always there, basically screaming “Hey, here are some things that you should not see”
If we were able to share a document without the sidebar I think that would be good enough. Even if that is a simple url-param, it would still be enough as 95% of the users would be non-technical or see this on mobile which would make the url-param as good as hidden.
I have multiple public spaces shared, but I don’t want everyone to see all shared spaces together in the sidebar.
My use case is that I share a library of materials with one specific group of clients. But I also have another space with different content where I didn’t want those clients to see. But, everyone sees all spaces in the sidebar.
While this works well for the Fibery team’s use case (where different complementary spaces are shown together), there are situations where each space needs to be shared independently.
I see, so you didn’t find a workaround for it either.
I get the same feeling that the Fibery team designed the product around their use case (one product) for which it works great, but when it comes to a situation like yours or mine, these sort of limitations show their head.
Well, Fibery is targeted as being ‘Your company’s operating system’ so indeed, the need to have silo’ed data stores as part of a multi-tenant setup is not a use case that has been prioritised.
And we’re still using it as our company’s operating system, but our company has more than one product that it needs to manage.
But fair, it’s no surprise this was not prioritized, and by the looks of it most other companies didn’t have this need either.
Well, there’s no problem working with multiple clients within the same workspace, provided those clients are invited into the workspace and granted access to (only) the things that they need to see.
The idea of a Fibery workspace being used as the backend server for multiple independent public portals/websites, which seems to be your use case, is not something that is being prioritised.
@Mircea_Braescu This video helped me setting up spaces for clients. It’s really good and it might help you. This solution makes private spaces for each client.
Anyway, the issue of having all public spaces on the sidebar remains. But the private space solution I shared might help your use case.
@Renato_Carvalho
Thanks. We have a multi-tenant setup and we managed to get it working quite nicely in terms of content, access rights and so on.
The public client portal is where we’ve now ran into issues.
The idea of a Fibery workspace being used as the backend server for multiple independent public portals/websites, which seems to be your use case, is not something that is being prioritised.
Sure, I’m not searching for a full blow solution which is why I was fishing for workarounds, one such workaround potentially being a url param to hide the sidebar.
But I get it, proper multi-tenancy is not coming any time soon, if at all, and there are no workarounds either.
