Workspaces: a working team structure in 15 minutes

Before you start

First, tell the four levels apart so everything doesn’t end up in one place.

The four levels

Checklist before you begin

• You can sign in; sign-in methods and security settings are in Account & security.
• One workspace owner is chosen, and it is a single person’s account.
• The team has agreed on a default time zone and main language.
• You have the email addresses to invite and know the least access each person needs.

Create a workspace in five steps

1. Name it. Use the organisation and its purpose, for example Slatepath Product Team. Avoid names like “test”, “temp” or “new folder”: the name appears in invitation emails and on new content.
2. Set the default time zone. Choose the time zone most members are in; it is the default for new content (for example Europe/London). It only changes how times are shown, not the data.
3. Choose the default language. Set it to the team’s main language; invitation emails and template text follow it.
4. Set visibility. Start with “Members only”. Open specific areas to guests only when you really need to, and never use public links instead of member access.
5. Name the owner. The owner is set at creation; keep it to one account so responsibility is clear. Once the structure settles, keep at least two admins so there is no single point of failure.

Inviting members, revoking invitations and handing over work

Invite a member

1. Open the member list in workspace settings.
2. Enter their email, choose a role (Member by default) and tick the projects they should join.
3. Send. The invitation shows as “Pending” in the member list.

Revoke an invitation

• Find the “Pending” entry in the member list and revoke it; the invitation link stops working.
• If they have already accepted, revoking no longer applies: transfer their content in each project first, then remove the member.

When someone leaves

1. List the projects and pages they own, starting with workspace-level content.
2. Reassign project ownership and page owners to current members, and check they can open them.
3. Only then remove the member. Don’t reverse the order: removing first makes it hard to find who owns what.
4. Move anything important out of their personal drafts explicitly before removing them.

Naming conventions and an example structure

Consistent names let new members find things without asking.

• Workspace: organisation and purpose, for example Slatepath Product Team.
• Project: topic (with the year if useful), for example Product decisions 2025, Customer onboarding.
• Page: topic and document type, for example Onboarding checklist, Interview evidence summary.
• Decision record: DR number and the decision in one line, for example DR-014 Pricing tiers.

Example structure

• Workspace: Slatepath Team
  • Project: Product decisions 2025
    • DR-014 Pricing tiers (status: decided; review: end of Q3)
    • Interview evidence summary (page)
  • Project: Customer onboarding
    • Onboarding checklist (page)
    • Q3 retrospective (page)

Tip: keep real customer names, contract values, credentials and personal data out of example content.

Create your first decision record

A decision record is valuable because it keeps the reason for a choice. Write these eight parts in one go.

What each field means and how to write it is in Decision records.

Setup checklist and definition of done

Checklist

• The workspace name follows the convention and doesn’t say “test” or “temp”.
• The team has confirmed the default time zone and language.
• Visibility is “Members only” and nothing relies on public links.
• The owner is named and knows it; there are at least two admins.
• At least one real project exists and members can open it.
• The first decision record exists, with an owner and review date.
• The naming conventions are written on the project’s about page.
• The invitation flow has been tested end to end with a test member.

Definition of done

A new member can find the project list and the decision records in one place without asking anyone, and every record answers three questions: who owns it, what it is based on and when it will be reviewed. Once that is true, the structure is ready; add content as you go.

Where to go next

Admins

1. Check members and roles; make sure there are no extra admins.
2. Fill in the defaults from the checklist.
3. Go to Integrations and connect your existing workflow.

Members

1. Open the projects you were invited to and check you can edit.
2. Read Decision records to learn how to write the fields.
3. Create a decision record for the first thing on your plate that needs a call.

Guests

1. Check which projects you can see and when your access ends.
2. Read Collaboration for the boundaries and how to communicate.
3. If you need more access, ask a workspace admin rather than asking for a public link.

Warnings

• Don’t use public links instead of member access. A public link can’t tell people apart; forwarding it hands over access. For controlled access, use member invitations and guest permissions.
• Keep sensitive information out of examples. No real customer names, contract values, credentials or personal data in sample structures, demo projects or screenshots.
• Archiving is not deleting. Archiving keeps history and links and moves content out of active lists, and it can be restored; deleting removes content. Archive first if in doubt.
• Don’t create duplicate workspaces. If you can’t find something, check member access and archive status first; a duplicate workspace splits members and decision history.
• Keep admins before making changes. When changing visibility or removing members in bulk, make sure two admins can still act.