A workspace in Tana is a space where you have control over who has access, what is contained within it, and what is allowed to show up in other workspaces. You can have workspaces that are completely separate from other workspaces, or they can exist in near parallel with your private workspace such as an archive of highlights. They can exist for your own personal use, or they can be used for collaborative efforts with other Tana users.
Everything you create in Tana is in a workspace: The workspace is a node with settings such as a list of its members, avatar, move targets, separate daily notes, library, trash, and workspace publish settings.
Everyone has a private workspace: all nodes that live here can only be seen by you and no one else.
Other workspaces can be places where big projects and collaborative efforts happen: Workspaces allow you to create separation between efforts that require their own space and schema in Tana.
See your workspaces in the sidebar: Workspaces have a separate section in the sidebar. You can also manage workspaces there and you can reorder the list as you like.
Add members to collaborate: Workspaces have rudimentary collaboration tools like adding members to a workspace, seeing the edit history is (time and user), and being able to notify users within a workspace of a node.
Workspaces can be published as read-only: This allows any Tana user with a HTML link to a node in this workspaces top open and view it.
The home node is the first node of every workspace. It's the place you end up when you click on any of the workspaces in the sidebar, or if you click on the avatar of your workspace in the breadcrumbs.
Curious to know how others organize their home nodes? Check out the Home node showcase showing different entries from the community!
The schema node is the place Tana will store any supertags and fields that are created ad-hoc, or sent to be "discoverable". It's a bit of a legacy node at this point, and the conventions for how to use this are currently in flux.
To go to the schema node:
Option 1: On the home node, go to the node options (ellipsis ⋯ button) > Open Schema
The library node is used for nodes that don't have a "place", either under the Home node or the Calendar nodes. Also, nodes are created in the Library if they're made inline using @-mention and they don't exist yet.
To go to the library node:
Option 1: On the home node, go to the node options (ellipsis ⋯ button) > Open Library
This 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.
Each workspace can be exported in JSON format. To export the JSON of a workspace:
On the home node, go to the node options (ellipsis ⋯ button) > Export workspace as JSON. It will immediately prompt you to enter a name for the file and will proceed to download if you accept.
This is a raw JSON export of your workspace. For technical reasons, there is currently no way for users to import these files back into Tana again. They can be used by our engineers to restore a workspace if need be, but our servers also take frequent backups of all workspaces so even if you don't download a JSON of your workspace and think that data has gone missing that used to be there, we can look at backups to find it again.
Your private workspace is also called your "root" workspace. All settings and many user-related features are tied to this workspace, such as Inbox, Quick Add, your timezone, keyboard shortcuts and much more.
If you look at the Workspaces section in your sidebar, you can always see your private workspace at the top. This is your workspace, and content that lives here cannot be accessed by anyone else, even if you leave references to your private content on shared workspaces.
New workspaces come without the default daily notes. You can create them by
Option 1: from your private day node. Go to Switch workspace and select the new workspace to navigate there. By virtue of having navigated there, Tana will create the necessary structure for the daily notes to exist in that workspace.
Option 2: command line. On the workspace title, run the command Set up calendar for workspace
Then, you may want to create a new default day tag. On a day node, press the ellipsis ⋯ button > Create default day tag
You just created a new workspace and now you want to use the same #task tag from your private workspace in this new shared environment. First let's talk about what not to do:
Why is it not simple to move supertags over from one workspace to another? When you create new supertags and fields, there are many hidden dependencies that get created in the background. This links them to the current workspace context. It's very hard and time-consuming to ferret them all out by deleting them or bringing them to live within the container of the supertag/field. In most cases it is easier and faster to recreate the supertags and fields in the new workspace.
If you really want to try to move an existing supertag, read this FAQ for some guidance.
A new workspace will be set to the timezone of the user that created the workspace. This means that if other members are added that are in other timezones, the way the dates and times appear to them will be adjusted based on their local timezone.
Example: If a workspace is set to an APAC timezone, 5pm EST will still appear as "Today" in AMER timezones even though it is technically "Tomorrow" in APAC time.
Currently you can only use Input API on a workspace that has less than 500k nodes. See this for more. While the Input API won't work on this workspace, you can still continue entering content into the workspace using the keyboard, AI or live transcription.
There is no simple way of doing this. The work is basically to manually move nodes from one workspace to another, and then leaving/deleting the one you don't want anymore.
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. To do this:
Create a new workspace, and in the title of the workspace, run the command Set [workspace name] as new root workspace
Any default tags and setups you had in your old workspace will not be brought over to the new workspace.
The old workspace can still be accessed via the sidebar.
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.
Everyone who is a member of a workspace can access the nodes that are owned by that workspace. This also applies if the reference appears in a different workspace that you also are a member of.
For example: let's say your company has a company workspace for all staff, and one for management only. If a manager copies meeting notes from the management workspace into her standup in the company workspace:
Managers will be able to see it because they are members of the management workspace. Meanwhile,
Staff will only see an alias of the node. They can't open or interact with it because it is owned by a workspace that they're not a member of.
In summary, 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.
This is how most of the Tana team collaborates in Tana:
For a fluid work experience, we make sure that our private workspace has Allow content from... the team workspace we work collaboratively in. This means that all content from the team workspace is available to be referenced from within our private workspace.
We use supertags from the team workspace to draft nodes in private. On your Today page, start with the supertag (like, your team's task/meeting/bug/standup tag) and fill what you need. When ready, select the node to bring up the node editor toolbar (it's sometimes easier to toggle selection with Esc). The first suggestion should be to Move to [workspace]:
This is the basic flow going from private to the shared workspace, and very handy for those of us who work primarily from our private spaces.. You can of course go to the shared workspace and work from there too, which means you don't need to move anything to make your work visible to your teammates.
FixedOnly show 'Unshare' for published read-only workspaces on the home node. ()
InfoInitial sorting of groups when Grouping by Workspace now follows the order of the workspaces in the sidebar. (Note that this is not responsive, if you want it updated, you need to turn off grouping and turn it back on again) ()
Fixed@-mentions will now only show recently opened nodes from workspaces you have "allowed content from". ()
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:
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)
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.
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.
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)
