Fields store structured information in Tana. They provide additional details about nodes such as their status, launch dates, social media profiles, order numbers, attendees, comments - anything you want to consistently record in the same way, everywhere.
Use fields to describe your data. For a Person, you may add fields (prefixed with > ; this also creates a field in Tana) like >Name, >Number, >Email, >Address, >Social media, all of which helps organize information concerning that person. One way to check if a field is right, is to think "has a" when adding fields. A person has an Email. A task has a Due date. A movie has a Release date.
Fields are like the columns of a database. Every node is a database entry, and the fields are consistent information about that node. You'll see this when you use our Table view.
Fields can be added to any node but even better is using our Supertags to create a template of fields you want applied every time you record a new #person, #task, or #movie. See Supertags for more.
Fields help you resurface, sort, group and filter your information. Find all your #ideas that have >Topic: Architecture. Filter #movies by >Director: Wes Anderson. Group #books by all >Genres. Tana has many ways of helping you surface just the right segment of information you need so you have a good overview, can make better decisions, and ultimately feel in control over the things you care about.
There are two main components of a field: the field definition and the field value. The field definition includes the name and type of field, as well as its configuration. The field value is the actual value of the field, which can be manually input or automatically initialized when applying a supertag.
Other than being used to record metadata attached to nodes, fields are also used in defining the query for search nodes to narrow down searches by specific field values, such as finding all #meetings where >Attendees include the value "Jane Doe". Fields can also be searched directly by adding the field and the system field value SET, or by adding the field definition through @[field name].
Fields show up differently depending on how the nodes they belong to are viewed. In List and Tabs view, fields are only visible when the node is expanded. In Table view, fields appear as columns. In Cards and Calendar view, fields can appear as metadata if selected from the Display option. See Views for more info on how to use fields in each view.
To configure a field, press on its icon to open a side panel with all field configurations.
Before you delete a field, consider whether it has been applied to any nodes or supertags. In the field configuration panel, scroll down and see the stats on how many nodes and supertags it’s been applied to.
If you have used it on 0 nodes/supertags, it’s safe to just delete the field. If you have used it on 1 or more nodes/supertags, consider finding and untagging them before deleting, or if it’s being replaced by another field, merging the old field with the new field.
When you delete a field that is applied to other nodes, these field will show a trash can icon. This follows our principles about deleting Nodes, Supertags, and Fields that have references elsewhere, which states that Tana will never delete data that is indirectly associated with another element that you delete.
Data Validation: Based on their type, Tana will validate their contents. There are no consequences for storing information that doesn't conform with the validation rules, except for the warning that will appear in the field itself.
Plain is the most flexible type of field. It acts just like any other place in Tana where you can write anything. Ideal for data that is unlikely to be repeated (e.g., Bug description) or does not need data validation (Options, Dates, Emails, URLs, etc.).
Options let you choose from a preset of options you can select from in a dropdown menu. The presets can be defined beforehand, or auto-collected as new values are added.
Pre-determined Options: Define options directly in the field configuration. Each node becomes an option and can be reference nodes. Nested nodes are not visible.
Sources of Options: Pull in one or more nodes whose child nodes you want to populate the options list. Nodes can be created straight in the field configuration, added as a Reference to a list of static nodes, or a custom Search node.
Auto-collect Values: Turned on by default on this field type. It automatically adds new values to the option list to make it easy to reuse values.
Options from supertag creates a list based on nodes with a chosen supertag. Writing in a new value will prompt Tana to suggest that it be tagged with the same supertag.
Supertag: The chosen supertag will be suggested for new values. Nodes with this supertag will become available as options.
Date fields accept Tana dates that link to the Day node. Press space or use @ to enter a date. Click on the date to change it or right-click for options like Go to day node and Open day node in new panel.
A field setting that specifies how their content should be autofilled when a supertag is added to a node. Auto-initialization allows fields to be filled out based on the context of their creation - when they were created, where in the graph they were created, who created them, and so on. This is different from setting default values to fields in the supertag config panel, which are static.
Good to know:
Initialization expressions are convenience functions, but are not live updating. So they won't change any prior field values from before you created the initialization functions, and you can change them after Tana fills a field if they need a manual touch.
This is only triggered for fields that are part of a Supertag template. Auto-initialize will not work for fields that you use otherwise.
Initialization is only triggered when a node gets the supertag applied to it. If the supertag gets updated with a field with initialization switched on, and the supertag was already applied to nodes, these nodes will only see the field added without any content initialized in it.
(From the archive: Stian's original demo (October 2022) on how Auto-initialization works. May have outdated info.)
Available on all fields. Copies the field values from the identical field on a node earlier in the tree.
Example 1: You could have a #quote tag with an Author field, and it could automatically initialize with the value from the Author field of the #book that it is nested underneath.
Example 2: You could have a "Related Project" field for your tasks, and then any nested subtasks would automatically have the same related project.
Only available on Options from supertag fields. Grabs a reference to the first node with this tag that it can find earlier in the tree.
Example: You could have a #quote tag with a Source field, which is an instance of #source. If you tag a #quote nested underneath a #source node, this function would auto-populate the field accordingly.
Sets the value as the user who triggered the creation of the field.
Note: Auto-initialize to current user is a bit of a stub and there's not much you can do with this information currently. It will be picked up again for development once we start focusing on collaboration and teams.
The place you create a field becomes the primary instance of this field which carries the field definition. This can be anywhere in the graph, including inside Supertag configurations.
If you delete the field definition or its owner, and you used the field in other places, they will now appear with a trash icon alongside the name. This is intentional to prevent data from being unintentionally deleted.
Tana Template consideration: Sometimes you want the fields to live in the supertag they were created in, so if you clone the supertag definition, it clones all the fields as well. If the fields were referenced, they would remain a reference in the cloned version, which is often not desirable.
But for most situations, to better preserve the fields you create it's recommended to move them to the Schema. Also, field definitions owned by the schema have priority when searching for fields.
Adding one or more commands here will add buttons to the field that will trigger the command upon being pressed. See Commands for how to create and configure commands.
The field definition is a special node that stores the settings of a field.
A field definition (1) versus a field (2) looks like this:
You can find it by putting your cursor in the field name, then press copy (Cmd/Ctrl+C) and put your cursor on an empty node and paste (Cmd/Ctrl+V).
Whenever you select an existing field to use, it is retrieving the settings from the field definition of that field.
When you create a brand new field, the field definition for that field lives in the place it was first created. If a field is created in a supertag template, it will only appear there unless you make it discoverable. This sends the field definition to the Schema.
NewGamechanger?? New commands to be run on tag template: "Convert template node to field" + "convert template field to node". What this does: Inside the content section of a supertag config, you can now convert fields to nodes, and nodes to fields. These will update the tag template / 'content', and all nodes that have already been tagged and 'initialized' with this tag template. Fields with values / content will be turned into nodes with children, nodes with children will be turned into fields with values. ()
NewThere is now a command to update existing instances when you change the default field value in a tag template ()
FixedFixed issue with field not getting focus when clicking hidden field. Sorry and you're welcome! ()
FixedFixed at least two edge cases where the new implementation of default field values in supertags broke adjacent workflows ()
FixedFixed bug where auto-init from ancestor field would create a reference to a an inline date instead of inserting the actual inline date. ()
In the command line, Set [field] -> [value] doesn't show all my fields, why?
Sep 26, 2024
Why is my field not auto-initializing?
Sep 26, 2024
Should I use the DUE DATE field?
Sep 26, 2024
How can I bulk set a value to fields?
Sep 26, 2024
How do I share a supertag from my private workspace to a shared one?
Sep 26, 2024
What does this warning mean: "Fields nested under other nodes or fields will not work as expected"?
Sep 26, 2024
How do I bulk delete a field and its values?
Sep 26, 2024
What does the system field "Number of nodes with this tag" do?
Sep 26, 2024
Can I show an alternative representation of a field value when building a title?
Sep 26, 2024
What are field definitions and how do I find them?
Sep 26, 2024
How do I set up relationships between nodes?
Mar 18, 2024
Examples
How can I find nodes based on a field value of an ancestor?
Sep 26, 2024
There is no way to build a search that is able to read the fields of an ancestor node. But, using title expressions, you can grab the field value of an ancestor node and have it part of the title of the node you're running the search on, making that information searchable.
TLDR: Use the ${sys:owner} title expression to pick up content from ancestor nodes and their fields.
This solution is great for Readwise users and came about when Maggie from the community wanted to search her Readwise highlights by the tags of the article/book it was taken from.
To do this, use ${sys:owner.Field}, and repeat sys:owner as many levels up as you need to go to target the right ancestor. In the case of Readwise highlights, you usually need to go up two levels. Check out the demo video:
Now with the information you need from the ancestor node baked into the title of the highlight itself, it can be used to search and filter those nodes.
While this solution came up in the context of the Readwise integration, it is a reusable pattern that can be applied elsewhere.
