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.
Fields = Adds metadata to any node.
Use fields to describe your data. For a Person, you may add fields (prefixed with
> ; this also creates a field in Tana) like
>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
#movie. See Supertags for more.
Fields help you resurface, sort, group and filter your information. Find all your
#ideas that have
>Topic: Architecture. Filter
>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.
>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
Creating a field anywhere is simple:
When in the Supertag configuration, fields can also be created by using the + Create Field button or by typing > as described above.
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.
There are nine field types in Tana:
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.
(Name updated from "Instance")
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.
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.
Number fields accept numbers only. This enables calculations in table view and allows setting max. or min. values of digits.
Note: This field changed names from User to Tana user in Week 7 / 2024)
Tana user fields prompt you to put in a user of the workspace with @, like @Olav Sindre Kriken in the Tana workspace.
URL fields store URLs/external links.
Email fields store email addresses.
Checkbox fields show the field value as a checkbox toggle instead of a field you can write in. They output Yes/No values.
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:
(From the archive: Stian's original demo (October 2022) on how Auto-initialization works. May have outdated info.)
Applicable to all fields. Copies the field values from the identical field on a node nested above. For example 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 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.
Get a reference to a node nested above with this tag.
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.
Get a reference to a random node with this supertag. You can set how many nodes you want to retrieve.
Example: You could have #JournalingPrompts and have three show up in a "Today's Prompts" field in your #Journal nodes.
Applicable to Date fields only. Adds today's date to the field
Example: You tag your workout logs and want to record the day you logged it.
Applicable to Date fields only. Adds the date that corresponds to an ancestor #day node that a node with this field would be owned by.
Example: In your daily node for next Tuesday, you tag a meeting. A date field with this initialization expression would be set to next Tuesday.
Sets the value as the user who triggered the creation of the field.
If switched on, will give a warning when field has no value. The warning is visual only and has no consequence.
Minimizes the field when part of a supertag.
Adds optional AI assistance for filling in this field, based on the name, description and contents of the parent node.
You can delete the field from here.
Question: Should you move a field to the schema?
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 referenced 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.
By default, a list of nodes will start to paginate at 100 items. Here you can configure another maximum number before nodes get put on the next page.
Tana has several different types of system fields.
Calculated system fields: Every node in Tana has calculated properties stored in these fields. To see a table of them, go here.
System-defined fields: Some fields are defined on the global level.
The field definition is a special node that stores the settings of a field. 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).
See Search nodes
Select the nodes whose field you want to set. Enter the command line (
K) and type
Set to see your options.
Set [field] command only works on field types Option, Instance, Tana User and Checkbox.
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.
Set [field] command only works on field types Option, Instance, User and Checkbox.