Workspaces
What is a workspace
First off - 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.
- [Note! For now, users you invite must have an existing Tana account]
- Once they accept, you'll be able to collaborate in that space.
Working with multiple workspaces
To effectively 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.
To create a shared tag, simply create the tag in the shared workspace.
Now that we have created this tag, you can add nodes with this tag directly in the shared workspace...
.. or you can create it in your personal workspace.
BUT you need to keep in mind that ONLY YOU can see this information for now.
You'll notice that there's a suggestive action to move the node to the shared workspace. If you click this, the node will be moved to the shared workspace, but a reference link will still be there in your personal workspace. This is very convenient, since it allows you to draft everything up and THEN send it over to the workspace when you're ready to share.
In all workspaces, including your private space, there is a setting to control which workspace tags should be used.
Move to command
You can also move nodes to another workspace with the "Move to" command. 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
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 personal 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... is where you can control which workspaces you see references from within this workspace. When you are a member of several workspaces, this controls what content is available to you when you look for nodes via @, or make search queries.
The nodes on your Home node also form the list of nodes you'll see when you expand the workspace node in the sidebar.
Related release notes
- newThe workspace members invite now allows you to invite multiple emails at the same time, and also does not auto close after invite. ()
- improvedThe command to publish a workspace as read only has been renamed to "Share workspace as read-only", to avoid confusion with the Tana Publish feature (which publishes a website based on Tana nodes) ()
Related FAQs
- Can I open the day node of another workspace by default?
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) orAlt(Windows) whilst clicking on a workspace in your sidebar to open its day node for today.Related docs:
- Can you build a wiki in Tana?
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:
Related docs:
- Does Tana have a 500k node limit?
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.
Related docs:
- How do I share a supertag from my private workspace to a shared one?
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 foe 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.
Related docs:
- Should I have just one or multiple workspaces?
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
Related docs:
- Why can I not drag nodes from one workspace to another?
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)
Related docs:
