Apologies if this has been discussed elsewhere. I couldn’t find it if so, which surprised me.
My question: When should you create a space? What factors should I weigh when deciding what to make into its own space? I’m very comfortable with the creation of “Types” (AKA Databases in Fibery?), and how to structure and relate them.
What I don’t think I have a good grasp on is when to separate groups of Types into their own space.
It seems like right now, maybe the permissions model is what I should understand the most, since that’s mostly based on Spaces?
Some examples:
I found a D&D template yesterday that had a number of spaces: World, Bestiary, Adventures, etc. Each space only had 2 or 3 Types inside of it. I like the separation of ideas this provides, but I don’t want a bunch of related-but-separate spaces in my sidebar. I could hide each of those spaces, then create another Space that doesn’t have any types, but includes many folders and views into those other D&D spaces. Alternatively, I could merge all of the Types into one D&D space. However, I worry that I will be limiting myself when it comes to sharing some of these types publicly in the future.
At my job, we have multiple departments like Development, Sales, Support, Onboarding, etc. I have created types specific to each department in their respective spaces, but for types that every department probably needs (Like People, Legal Entities, etc), I’ve placed them in a separate space called “Database”. This is great because it keeps things organized, but it also means that with the current permissions features, essentially every person in our company is going to have at least Read access to every “Person” in Fibery, whether or not it’s relevant to their role (and regardless of the sensitivity of the data inside that Person).
Should I restructure the spaces I use to be based on data sensitivity and privacy instead?
What are best practices for this? What does the Fibery team recommend? What has worked for you?
This is always an interesting question. Here are some internal thoughts that will help you to think about Spaces
I should say I regret we’ve made Spaces mandatory. It works not very well for some use cases, like when a company works on many products with many teams it can be challenging to setup and maintain. Now with the new per-entity permission model we are re-thinking left menu and try to find options how to make it work better.
Usually Space = Process. For example, it can be CRM or Marketing, or Development. For example, here is the list of some spaces in our own Fibery account
Having common databases in some general Space might be OK, but I feel that it is better to try to add them to the most relevant space. For example, Legal Entity maybe closer to CRM Space.
Right now permissions and left menu organization are indeed top 2 reasons for Spaces, but new permission model change that and with left menu changes maybe we will provide more options here and Space will become optional. However, we did not settle the solution…
If you describe your use cases in Fibery it will be easier for me to recommend some setup.
Currently Spaces are the only way to control access/permissions, so that can decide many cases for now.
Once per-entity permissions are working (soon!) then there will no longer be a need to use Spaces for controlling access.
Until the Left Menu is “re-worked”, Spaces are also the main way organize the contents of the Left Menu, because all Views and Folders and Documents must exist within some Space (or My Space).
So for example I create Spaces simply to organize different functional categories in the Left Menu for most users (containing hierarchies of views and Documents), but these “organizational” spaces have no DB’s - all my DB’s exist in other Hidden Spaces.
@mdubakov are there any performance considerations to using the method @Matt_Blais describes above? Or is it all negligible? I don’t know how Fibery works behind the scenes… (super curious though, want to invite me to the codebase readonly? )
Awesome - total trust in your vision and how you go about implementing it. Exciting stuff! I haven’t been able to put my finger on it yet, but there is something that bugs me about the Fibery sidebar and Navigation in Fibery, or just makes navigating between spaces annoying… Spaces being optional makes a lot more sense to me.
I’m attempting to build our company’s “digital double” into Fibery. We’ve been using other systems previously, and now, I’m working on unifying everything into Fibery. Nothing I’m building has gone live yet, so I still have quite a bit of flexibility at this point. We’re a franchisor, so we own a brand and business model, and we help people open stores within the franchise brand. The lifecycle of our data is sort of like this:
People reach out to us about franchise opportunities. Their data gets loaded into Fibery. We create a Person, Entity (usually a family at this point, later on, a legal entity or company), and an Opporunity.
We conduct them through a sales process, using the Opportunity entity as the dashboard for that person’s process. People and Entity types are housed in a company-wide “Database/Data Warehouse” Space. Opportunities are housed in the FranDev space (Franchise Development, the industry lingo for Internal Sales).
External task portal systems guide the candidates through tasks they need to complete independently, like filling out forms, watching videos, etc. Completing these sorts of things uses n8n automation workflows to create an abstracted data type in Fibery (located in the Event Logs space), which is then attached to the Opportunity.
There is also a Data Types space which I’m using as more of a lookup for the automations, to correlate 3rd party event webhooks with whatever version of the Sales Process the Opportunity is using (as we often have to re-publish legal documents or change the wording of our presentations, and we need to keep track of which versions are being used. We also might create new iterations of forms, and need to handle the new schemas in our automations and make sure each version gets put into Fibery correctly.
)