Structuring My OS in Fibery – Am I Doing It Right?

[Edan]

Hey everyone!

Coming from Notion/Coda, I’m trying to build my OS in Fibery but feel like I might be structuring it wrong.

Right now, I’ve placed all my databases inside a Backend Space and use views in the default workspace to access them. But I’m running into two issues:

1. I can’t move databases out of a Space and into a regular folder.

2. Breadcrumbs always show Default Space > Backend —would love to simplify or hide this.

Is this the best way to set things up? I want to make sure I’m on the right track.

Would love to see how others are structuring their setups!

[Michael_Ichter]

How you organize your workspace depends on what you need to do. For example, is this workspace only for you? Are there clients who will need to access certain things? Are there other employees who need to manage databases or other parts of the workspace?

In general, your setup is valid. I myself have a “Backend” space that is a store for certain broadly used databases, but I’m not aware of a way to remove the breadcrumb text at the top of the views (and personally I like to see this because it helps me to keep the context in mind).

@Edan

I can’t move databases out of a Space and into a regular folder.

Databases have to be stored in a Space, and I believe they stay at the top layer of that Space. If you want to organize databases, you could create multiples Spaces and use them like folders. You could also create a folder on the top level of the left sidebar and put any Spaces into it. Just consider how creating multiple Spaces might affect any collaboration you might do since sharing a Space with users provides certain permissions to the databases within that Space.

[RonMakesSystems]

I personally don’t use a “Backend” space often. Fibery has a natural backend that notion does not. When you set up your databases, no views are created and non-admins and non-creators cant see them. Hence, the backend. Spaces are essentially just database folders. It makes it easier to organize, share with team, etc. With new Fibery features out recently (share database with group, create views outside of spaces) technically your set up could have the same functionality. But I believe its less handy in the long term, as you create more databases that backend space is going to be quite unwieldy. Think of each space like a single purpose app. One is a project manager app, one is a CRM, one if for invoicing. Each app has its own purpose, but are interconnected.

Advice:

1. I’d put all the CRM databases into the Sales CRM space.
2. Stay consistent with database naming. Singular or plural (Fibery automatically converts where needed, but if you ever go into scripting, having this inconsistent will be annoying to check every time)
3. Keep the backend space only for things that are really interconnected across spaces. (If Tasks can both for the CRM and the Project Manager for example.)

Will it work like this? Yes. It just might be problematic when you grow / things get more complex / add more people into the workspace.

Welcome to this beautiful, powerful tool!! It’s a journey to understand how it all works, so feel free to share on here if anything isn’t working like you want it to. Have fun building!

[mdubakov]

We usually advice to create Spaces and put databases into relevant Spaces. You can think about Space as a Process. In your specific case maybe you should have spaces like CRM, Projects Tracking, Company, Notes and move relevant database to these spaces.

Spaces

Backend space is usually an anti-pattern in Fibery, but you can have it for some very specific things that most people should not see, like World database or Dates database

[Edan]

Thanks for the insights, everyone!

Spaces give me Monday vibes —and not in a good way. We constantly struggled to track where automations were firing, and as rules piled up, navigation became a mess.

I’m also curious—how do you handle databases that span multiple Spaces?

Take Notes, for example. A note might belong to Sales CRM, but it could also be linked to a Task in Operations/Workflow .

Do you use a global Space for shared entities like Notes and Tasks? Since these can live in different contexts—Sales CRM, Projects, Changelogs—how do you keep things structured without losing your way?

Edit: Just read again through everyone’s responses and realized that @RonMakesSystems answered my main question. (Still doesn’t eliminate my concern about this becoming cumbersome.)

[Michael_Ichter]

Sounds like your workflow is a bit different than ours as we mostly organize things around departments. We have some databases that are used globally (e.g. tasks, docs, meetings), but people should not be able to see every entity within them, so we have those in a separate Space.

Another case of a multi-Space database is our database for recruits, and recruit entities needs to be accessed by the Recruitment department (a Space) and the Onboarding department (another Space). The database is located within Recruitment, and once a recruit entity is moved to a certain state, it is automatically shared with Onboarding, appearing in a view within that Space (and a notification being sent to members of that Space/dept).

[Edan]

Thanks again for all the feedback, everyone!

I’m back with an updated version that I think aligns more with the Fibery way.

Here’s how I’ve structured our setup so far:

Home

This is the team’s starting point and where most of the day-to-day happens. We’ve added views for ongoing work, knowledge base, and SOPs.

• No databases live here to avoid permission issues—instead, we pull in views from other Spaces.

Software Development

This Space houses our core work databases, covering:

• Client service-based projects (Web Development & Marketing)

• Our SaaS/Software solutions

CRM

All sales-related documentation and activities live here.

• Right now, it’s mostly just me, but I’m hoping to onboard more folks soon.

• Still debating: Should sales team members have views within Home or only access the CRM Space directly?

Global

This is where shared entities live—things used across multiple Spaces.

• We also use it for mini-databases with repetitive items/variables.

• Example: Statuses for Bugs and Tasks are the same, so we can store them in a Global database and connect via relationships. This is a bit of a Coda approach, and I’m not sure if it’s the right move or a potential mistake. Would love to hear thoughts!

---

Current Structure – Feedback Welcome!

The screenshot below shows how it all comes together. Would love to hear your thoughts—your feedback has been incredibly helpful!

P.S. – Hello, Fibery for Mac app! Damn, it was a delight to discover and start using you.

[Chr1sG]

@Edan I think your latest setup looks good
One thing to think about wrt Spaces and Databases is that at the moment* if you share a Space (in order to give someone access to a view within the Space) you will also be giving access to the Databases in that Space.
e.g. if you create a board view in CRM space and want to share that view with salespeople, you need to share the CRM Space with at least viewer level access. Which means all salespeople get viewer access to all dbs in the CRM space. Maybe that’s not desirable, and you only want them to see Companies/Contacts they are assigned to. If so, you do need to think about creating a space to host views which can be shared, separate from databases, where the sharing might be on a per-entity basis.

*we are working on decoupling views and database sharing, so that you can share the views in the space without sharing all the dbs

[Edan]

Thanks! If I understood correctly, would it be okay for the team to live in my Home Space, which doesn’t contain any databases? That was one of the main reasons I chose this setup.

We would simply need to add a view in the Home Space so users can see entities from the CRM Space without having full access to the database itself.

[RonMakesSystems]

If you only share the home database with your team, and make a view inside that space with items from a database in the CRM space. Unless you give database access, they will see an empty view. Sharing is not only about what you see in Fibery, it is also about the permissions you have to access. If they don’t have permission to the database, they can’t see any entities.

I would recommend to keep the views and databases inside the relevant spaces. Then link things together as needed across spaces. Also before you invite users in, make another user on another Chrome profile as a member to see what they see. That’s the only way to test permissions at the moment unfortunately. You can do the classic “email+member@email.com” for another user with your same email. If you’re paying, you can cancel/deactivate the user and add another and you’ll get credits for the time you didn’t use.

But I will say that I’m a bit confused about what you’re trying to achieve… I know there’s Monday.com trauma (i feel it too hahah), but Monday’s workspaces are not like Fibery’s spaces. You can be comfortable splitting it up without compromising on connectivity.

[Edan]

I’m primarily trying to keep users within a single space to streamline their experience. Otherwise, they’ll have to constantly switch between spaces and navigate different views.

Similar to Notion and Coda’s world, it feels more intuitive to have a home environment where everything is easily accessible in one place.

That said, your last comment made me realize that the Home Space isn’t a good fit for Fibery.

It’s not ideal, but I’ll adjust the setup so users will navigate between spaces where the relevant views reside.

[helloitse]

@Edan

I’m primarily trying to keep users within a single space to streamline their experience. Otherwise, they’ll have to constantly switch between spaces and navigate different views.

This is not the way Fibery thinks. It’s possible to do this but you’ll have to make compromises that it looks like you don’t want to make.

I read your other post about limiting access to opportunities within the CRM. Here’s my take:

It’s helpful to remember that when Fibery started Spaces were called Apps. The idea was for each app in the sidebar to be self contained and perform a function for the business. Theyre more flexible today but its good context. So a space in Fibery is the equivalent of a Coda doc.

Until recently Spaces were the primary permissions unit. When you want to control access in bulk, you use a space.

I’ve not seen anyone recommend this yet but it looks like the best fit for your use case- decouple sales activity from contact storage. Sales Space for Opportunities, Proposals, etc. CRM for client relationship. Afterall, not all crm apps are sales crms.

Other context that may help here - your first swing at a default database makes me think you’re coming from Notion moreso than Coda. It’s easier to consider Fibery as a collection of Coda docs.

Finally home can be a top level folder.

[mdubakov]

@helloitse

I’ve not seen anyone recommend this yet but it looks like the best fit for your use case- decouple sales activity from contact storage. Sales Space for Opportunities, Proposals, etc. CRM for client relationship. Afterall, not all crm apps are sales crms.

This is a good advice. You can create CRM folder on top and have several spaces inside indeed.