Learn

Setting up a collaborative workspace: a complete guide

The problem with jumping straight in

Most shared workspaces fail not because of the tool but because of what happens before the tool. Someone creates a few folders, shares the link, and then watches as different people organise things differently, naming conventions diverge, and nobody knows where to look for anything.

A little upfront thinking prevents most of this. Not extensive planning, just enough to agree on structure, processes, and how information flows before you invite anyone. The time you spend on this is repaid many times over in the collaboration that follows.

This guide walks through four steps: deciding what the workspace is for, mapping the processes it needs to support, building the structures, and reviewing before you open it up.

Step 1: decide what the workspace is for

Before building anything, get specific about what you want this workspace to handle. Not everything, at least not initially. One well-defined scope is better than a sprawling system that tries to do everything and ends up doing nothing well.

Some ways to frame this:

What will people use this workspace to do every day? The answer to this shapes the structure more than anything else.

What stays out? Deciding what doesn't belong in the workspace is as important as deciding what does. If you have internal documents in Google Drive, that might stay there; the collaborative workspace might pull them in for search without duplicating them.

Who needs access to what? Different people often need different parts of the workspace. Understanding this in advance helps you set up access properly rather than giving everyone access to everything and losing the ability to separate sensitive materials later.

A concrete goal helps: "handle client orders," "manage the production pipeline," "run the editorial calendar," "support the research project." That sentence shapes everything you do next.

Step 2: map the processes and information involved

Once you know what the workspace is for, map out the moving parts. There are two types:

Processes are the things that happen, the actions and workflows. Orders being placed, content being written, bugs being reported and fixed, feedback being given. These are dynamic: items move through stages.

Information is the more static material that supports the work: reference documents, client records, templates, guidelines, recipes, specifications. These don't move through stages; they're consulted.

Getting clarity on both before building the structure prevents the common problem of mixing them up: ending up with a workspace where active tasks and reference material are jumbled together.

Top-down vs bottom-up

If you already know how your process works, use a top-down approach: start with the main areas or functions, then fill in the steps and sub-components.

If you're less familiar with all the pieces, a bottom-up approach works better: list every activity or piece of information you think you'll need, and then group related items together to find the natural areas. This often surfaces things you'd have forgotten if you started from the top.

Either way, you're looking for the same thing: a clear picture of the main areas the workspace needs to support, and the key activities and information within each.

Step 3: build the structures

With the map in hand, create the top-level structure in your workspace. Each main area gets its own section or space. Within each area, add the specific process stages and information items it contains.

Process structure

For any process that involves items moving through stages, a clear sequence of stages makes it obvious where everything is at any given moment. A simple production workflow might look like: Backlog → In Progress → Review → Done. A client order process might look like: New Orders → In Preparation → Ready for Collection → Collected.

The stages should reflect what actually happens, not an idealised version of the process. If work regularly sits in a particular state that you haven't named, add a stage for it. If a stage is always empty, question whether it's actually part of the process.

Information structure

Reference material should live separately from the process stages so it doesn't get confused with active work items. A Recipes section in a bakery workspace, a Style Guide in a content workspace, a Client Records section in a client management workspace: these belong in their own clearly labelled areas, consulted as needed rather than mixed in with the items moving through the workflow.

Push vs pull

When work moves from one area or team to another, you need to decide who is responsible for the handoff.

Push system: the person completing a stage moves the item to the next one. When a baker finishes an order, they push it to the decoration stage. The decorator doesn't have to monitor the bakery section; items arrive in their queue.

Pull system: the person in the receiving area checks for ready items and pulls them in. The decorator monitors the bakery's done pile and pulls items when they're ready for decoration.

Push tends to work better when you want each person focused on their specific area without having to monitor elsewhere. Pull tends to work better when the receiving team has variable capacity and needs to manage their own intake.

In Fabric, a canvas can represent the full workflow visually, letting everyone see the state of work across all areas at a glance. This is particularly useful when the workspace spans multiple people with different responsibilities.

Sharing and access

Once the structure is built, sharing is simple but worth thinking through carefully.

In Fabric, you can share any space, folder, or individual item with specific people at different permission levels: viewer (can see but not edit), editor (can add and modify content), and owner (full control). Sharing a folder gives the person access to everything inside it, so structure your workspace so that what you share is exactly what each person needs to see.

For most teams:

Core collaborators get editor access to the areas they work in.
Clients or external partners get viewer or editor access to a dedicated client folder only.
Sensitive materials (financial information, confidential documents) stay in separate folders not shared with everyone.

For deliverables or materials you want clients or external stakeholders to access without requiring them to create an account, Fabric's publishing feature turns any folder into a shareable public page at a URL. You can password-protect it for confidential materials.

Step 4: review before you open it up

Before sharing the workspace with collaborators, walk through it with fresh eyes and ask a few questions:

Does the structure support the goal you defined in step one? If there are areas or stages that don't clearly connect to that goal, question whether they belong.

Is there a clear separation between process flows and reference information? Items in motion and static reference material should be distinguishable at a glance.

Is it obvious what to do in each area, or would someone new need a manual to figure it out? If the answer is the latter, add short descriptions to each section explaining what belongs there and what happens to it.

Have you decided on naming conventions? Inconsistent naming is how shared workspaces become unsearchable. Agree on how you'll name items before anyone else starts adding things: will you use client names, project codes, dates, or something else? A template for recurring item types ensures consistency without requiring everyone to remember the rules.

The goal of the review isn't perfection. It's a reasonable starting point: simple enough to explain in ten minutes, structured enough that people know where things go. Every workspace evolves with use. What you're trying to avoid is building something so unclear that the evolution is in the wrong direction from day one.

Getting collaborators set up

When you do share the workspace, a brief onboarding makes a significant difference to how well it gets adopted.

Explain the goal: what the workspace is for and what stays outside it. Explain the structure: what the main areas are and what goes in each. Explain the key processes: how items move from one stage to the next, who is responsible for the handoffs, and what done looks like. A five-minute walkthrough is better than a written document that nobody reads.

For recurring processes, checklists and templates remove the need for people to remember the steps. When someone creates a new order, a new piece of content, or a new support ticket, they start from a template that captures the required information and follows the agreed structure.

For complex projects with multiple moving parts, Fabric's AI assistant can answer questions about the workspace content without requiring people to navigate to the right folder: "What's the status of the Henderson order?" or "Where are the brand guidelines?" works as a natural language query across the shared library.

As the workspace evolves

No workspace design survives first contact with real use unchanged. Things you thought would be separate should be combined; processes you thought were simple have more stages; information you thought was reference material turns out to need its own workflow.

Expect this and treat it as useful signal rather than failure. Review the structure with your collaborators after the first few weeks: what's working, what's confusing, what's missing? A few early adjustments based on real use produce a workspace that actually fits the work rather than one that fits your best guess about the work.

The PARA method provides a useful framework for thinking about how to organise the workspace's content over time: active projects, ongoing areas of responsibility, reference resources, and archived material. This distinction becomes more important as the workspace grows and the line between active work and reference material starts to blur.

Frequently asked questions

How much structure is too much?

Enough that people stop knowing where to put things, or that navigating the workspace takes longer than the work itself. A workspace with three or four top-level areas and clear stages within each is usually sufficient for most teams. Add structure in response to specific friction rather than in anticipation of problems that haven't arisen.

Should everyone have access to everything?

Usually not. Giving people access only to what's relevant to their work keeps the workspace less overwhelming for them and keeps sensitive information appropriately contained. Fabric's per-folder sharing makes this easy: you can share exactly what each person needs without giving them access to the whole workspace.

How do we handle materials that are shared across multiple areas?

Either keep one copy in a shared reference area that all areas can access, or accept that some duplication is necessary because different teams will want to organise their version differently. The right answer depends on how much the areas actually collaborate. If teams rarely interact, duplicate reference materials and let each area organise them as they prefer. If they collaborate constantly, a shared reference area with clear ownership works better.

What if different team members want to organise things differently?

This is the main risk in a shared workspace, and the main reason to agree on structure before inviting collaborators rather than after. Once you've defined the top-level areas and the key processes, individual preferences can be accommodated within each area as long as the structure at the shared level is consistent. The naming conventions, the process stages, and where to find reference material need to be agreed; how each person organises their own working notes within their area doesn't.

When should we start fresh vs adapt an existing workspace?

If your existing workspace is well-understood and just needs refinement, adapt it. If it's grown organically to the point where nobody is sure what's where or why, starting fresh is often faster. Before starting fresh, export or archive what's there rather than deleting it, since semantic search means older materials remain findable even without a clean structure.