Collaboration

Workflowy can support a shared list between two people, a team workspace, or a repeatable system for working with clients. Successful collaboration depends less on building an elaborate structure and more on making purpose, ownership, and handoffs easy to understand.

Decide what belongs in Workflowy

Start with one clear outcome, such as managing client requests, coordinating a project, maintaining a team wiki, or organizing household responsibilities.

Define what the shared space will contain and what will stay elsewhere. A narrow first version is easier to explain, test, and improve than a workspace designed for every possible use case.

List the people involved, the information they need, and the processes they perform. If you already understand the work, start with its main areas and work down into details. If the process is new, list the individual activities first, then group related activities into areas.

Build a simple shared workspace

Create one parent node for the shared workspace, then add only the main areas collaborators need. A useful starting structure is:

Shared workspace
  Start here
  Work
  Reference
  Discussions

• Start here explains the purpose, structure, owners, and working rules.
• Work holds active items and visible stages.
• Reference stores information people need while doing the work.
• Discussions gives collaborators a predictable place for questions and suggestions.

Adapt these labels to the work instead of preserving a generic template. When an area becomes difficult to scan, add structure at that point rather than designing several empty levels in advance.

When the structure is ready, use Share and collaborate to invite specific people or create the appropriate sharing link. Give each person only the access they need.

Define ownership and handoffs

For each recurring process, decide who creates an item, who acts on it, and what happens next. Pay particular attention when responsibility moves between people or areas.

There are two common handoff models:

• In a push flow, the person finishing one stage moves the item to the next stage.
• In a pull flow, the person responsible for the next stage checks a queue and takes the item when ready.

Either can work. The important part is that collaborators know who is responsible, where ready work appears, and how completion is shown.

Visible stages such as Inbox, In progress, Review, and Done are often easier for a new collaborator than a large set of status tags. Use boards when moving work between columns makes the process easier to understand. Use tags and mentions when an item needs labels or someone’s attention without changing location.

Keep rules brief and place them next to the work they govern. Document exceptions only after they occur often enough to justify a rule.

Onboard collaborators

Before inviting someone, make sure Start here answers these questions:

• What is this workspace for?
• What belongs in each main section?
• Who owns each area?
• How does work enter, move through, and leave the workspace?
• Where should someone ask a question or suggest a change?

Add one or two real examples of the main workflow. Concrete examples are usually easier to follow than abstract instructions.

Ask a new collaborator to read Start here, complete a small real task, and raise questions in the agreed discussion area. Update the documentation when a question reveals an unclear structure or rule.

Use comments when discussion should stay attached to a particular item. Mention a person with @ when you need to notify them directly.

Use mirrors safely in shared spaces

Mirrors let the same live content appear in several locations. They are useful for team dashboards, personal task views, and shared reference material, but permissions matter.

When a mirrored item is used in a shared space, keep the source mirror inside that shared space. Create the item in the share first, then mirror it into private or secondary views. If a private virtual mirror is placed in a share, other collaborators may see a permission error instead of its content.

To identify the source, open the node menu, select the option to view its mirrors, and look for the item labeled as the source.

Work with clients

Choose a flow based on who usually starts the work:

• In a client-led flow, the client submits a request, you move it through work and review, and the client approves the result.
• In a provider-led flow, you provide a lesson, draft, or deliverable, the client responds, and you review or advance the work.

A simple client space might contain Start here, Inbox, In progress, Review, Done, and Reference. Remove any stage the relationship does not need.

Turn the structure into a template, create a fresh instance for each client, and invite only the people who should access that client’s material. Use notes beneath section headings to explain what belongs there, and keep reusable resources in a library that you copy or mirror into the client space when needed.

Review and simplify

After collaborators have used the workspace, review it together. Look for work that gets lost, unclear ownership, duplicated information, unused sections, and rules people repeatedly forget.

Fix the smallest underlying problem. Rename a section, clarify a handoff, remove a redundant stage, or add one example. A collaborative workspace should become easier to use as the team learns, not steadily more complicated.