Workspaces

Workspaces in Tana
Last updated: September 3, 2024

What is a workspace

A workspace is a separate graph in Tana, where you can control who has access, you can create tags for that particular workspace and you can control which, if any, tags from other workspaces you want to allow.

Each workspace has its own library and you can export a JSON structure of the entire workspace.

Setting up a workspace

If you look in your sidebar you can see your private workspace at the top. This is your personal workspace, and it cannot be shared with anyone else. Anything you put in here, must explicitly be shared with other workspaces, so you can be sure that data from this workspace won't be seen by others.

In the bottom of the sidebar, you will find a plus-sign where you can accept invites to workspaces created by others, or you can create your own workspaces. Workspaces you create or accept invites from will be shown beneath you private space.

Let's go ahead and create a workspace to share with your team:

  • Click create workspace, and give it a name
  • After it's done, you can click the Members options to invite other users to your workspace. Users must have an existing Tana account.
  • Once they accept, you'll be able to collaborate in that space.

Working with multiple workspaces

Schema

To work with multiple workspaces, it's best to create supertags in the workspace where you want the shared data to live. You can still use the tags in other workspaces, but if you create a tag in your personal workspace and use it in a shared workspace, only you will see that tag. Similarly if you link a node from your workspace without moving it over, the title of the node will show, but only you will be able to expand and see the content of the node.

Membership

The workspace membership is the security boundary for whether content is visible to users or not. Whether a user can see a node depends on 1. where the node lives, and 2. if the user is a member of that workspace. Anything that lives inside your private workspace can never be referenced to anyone else.

Move to command

Whenever you want a node in your private workspace to be seen by members of another shared workspace, you have to move the node to the workspace with the "Move to" command, or press Cmd/Ctrl+Shift+M.

Moving something to another workspace changes the ownership of the node from being under your private workspace to being owned by the shared workspace. By default you have the option to move node to the target workspace Home node, Today or Library. But if you open the shared workspace and click settings, you can create other move targets by either copying or pasting the nodes you want as targets or by @-mentioning them

Create daily notes

Workspaces come without the default daily notes. You can create them by using the command Set up calendar for workspace

Workspace settings

Each workspace has settings of their own. You can access the settings in the following ways:

  • Workspace node options (three-dotted button to the top-right) > Open settings
  • The command Open settings from within the workspace in question

Deleting a workspace

Your private workspace: You are not able to delete your main private workspace. You can, however, swap your old private workspace with a new one, and then you can delete it like a regular workspace.

Other/shared workspaces: You can delete a workspace by being the last person to leave it. It becomes completely unavailable, nobody has access to the encrypted data and it is queued for deletion.

Home node

The Home node is the root node to all other nodes that exist in a Workspace.

The workspace at the top of the sidebar is your private workspace, which no one but you can see the contents of. Clicking your personal workspace will send you to your home, which acts like the base of your platform.

Workspace profile: This defaults to the initials of the Workspace name. You can replace it with an image by clicking it and uploading a new picture.

Schema: The place where all supertag definitions are saved when creating them. Field definitions can also be saved to Schema if you choose - via the field configuration panel.

Library: Created items that don't live in a specific context.

Settings: The personal preferences to your account/workspace, such as your custom keyboard shortcuts.

Options > Allow content from... controls which adjacent workspaces can populate the results of search nodes and autocomplete actions like @-mentions within a particular workspace context. This setting can be custom set from all workspaces. Examples:

  • You can set it so all content from every workspace you're a member of is available to you from within your private workspace by allowing content from everything there.
  • You can keep Workspace A completely isolated from retrieving anything from other workspaces you're a member of by unchecking everything there, while allowing Workspace B to find things from Workspace A still.


Related release notes

  • FixedFixed bug where pure dates (with no time) in shared workspaces would also change depending on time zone. ()
  • InfoThe command line "Publish workspace" is now "Share workspace "name" as read only", to avoid confusion with Tana Publish. ()

Related FAQs

Question

  • Can you build a wiki in Tana?
    Sep 26, 2024

    Absolutely: The most common place to do this is on the Home node. Here are some examples of top level wiki structures, usually arranged on workspace home nodes:

  • Should I have just one or multiple workspaces?
    Sep 26, 2024

    We suggest you keep one workspace until you need to do one of the following things, many of which will trigger/require the creation of a new workspace anyways:

    • Collaborate with someone in Tana (requires you or the other to create a workspace and invite each other to)
    • Import content from Roam, Logseq, Workflowy, or other (this automatically creates a new workspace for the purpose of the import)
    • Create a holding space (separate from you private workspace with no "Allow access from.." for testing other people's templates and setups before you bring it in to your active workspaces)
    • Creating a Tana Template (which means you want a clean, self-contained workspace setup so you know you're creating a template with no references pointing to other workspaces)
    Source of FAQ: Tana Community Resource Hub
  • Can I open the day node of another workspace by default?
    Sep 26, 2024

    It is not possible to change which workspace's day node you open by default; it is fixed to your private workspace's day node.

    However, open the sidebar and hold Option (Mac) or Alt (Windows) whilst clicking on a workspace in your sidebar to open its day node for today.

  • How do I share a supertag from my private workspace to a shared one?
    Sep 26, 2024
    Currently, the easiest and most foolproof way to do this is to not share it but instead build the supertag, with its fields and anything else necessary for the supertag to work, from the ground up in the new space.

    That said, if you still want to move a supertag over that exists only in your private workspace, the main work is to ensure that there's nothing in the supertag that references something in your private workspace, otherwise it will appear as broken to others once it's moved.

    It's like packaging up a zip file. You can't just zip up a bunch of shortcuts, you need the real files in there or the recipient will only see broken shortcuts.

    You'll also have to remember to move over other things like field options, commands, and ensure that no saved view options contain elements from your workspace. Basically, you must ensure that nothing you're moving over from your workspace contains references from your workspace.

    To bring all nodes (except system nodes) into the supertags, fields and commands you want to move, use the command "Bring referenced node here". Alternatively, you can move each necessary node separately too if you for example want the field definition to exist outside the supertag. But the key is that everything that is connected to what you're sending over gets sent over too, otherwise there will be missing pieces.

  • Does Tana have a 500k node limit?
    Sep 26, 2024

    As of February 2024, when a workspace hits 500k nodes, the API will not sync any new information to the workspace anymore.

    The 500k node limit per workspace only applies when information is being added from an external service like our Input API or Readwise. This is a temporary precaution we've put in place to prevent external services from overloading Tana while we're still at the pre-launch stage.

    You can still use a workspace that has well over 500k nodes as long as you're writing things yourself. There's no performance hit at that mark.

  • How are AI credits used on shared workspaces?
    Sep 05, 2024

    Whoever triggers the request for an AI command or adds the Meeting agent will have the credits charged to their account.

  • Why can I not drag nodes from one workspace to another?
    Jan 11, 2024

    In regards to error messages:

    • Cannot move notes between different shared areas
    • Cannot move nodes between different workspaces - use move command

    The reason for this message is that nodes are not made to easily move between workspaces. The workspace they belong to dictates a lot of things, such as permission to view and edit. This will become more important in the future when we build up the collaboration functionality but for now there are a couple of methods you can use to move nodes from one workspace to the other:

    • Option 1: Cut (Cmd/Ctrl+X) and Paste (Cmd/Ctrl+V) into new workspace
    • Option 2: Cmd/Ctrl+K > Move node to > choose workspace and target (you can set custom targets in addition to the defaults of Today/Library/Home etc)

Examples

  • How can I find references in one workspace that are owned by another?
    Sep 26, 2024

    To find all references in a workspace that are owned by another workspace:

    1. Go to your workspace home

    2. Create this search as a direct child of the workspace home node:

    • GRANDPARENTS DESCENDANTS WITH REFS
    • >NOT GRANDPARENTS DESCENDANTS

    To limit the search to specific workspaces, add the system field Workspace and specify the workspaces you want to target there.