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 >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.


Creating a field

Creating a field anywhere is simple:

  1. Stand on an empty line
  2. Type > to create a new field
  3. Give the field a name, or select from existing ones
  4. Hit tab to fill in its value
  5. To further configure the field, click on the field icon or use the shortcut Cmd/Ctrl + K and select "Configure Field".

When in the Supertag configuration, fields can also be created by using the + Create Field button or by typing > as described above.

Deleting a field

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.

To delete a field:

  • Option 1: Go to Field configuration panel. At the bottom there’s an action to Delete the field.
  • Option 2: Find the original Field definition and delete it.

Configuring a field

To open the config panel:

  • Option 1: On the field you want to configure, press on the field icon
  • Option 2: Go via command line and press Cmd/Ctrl+K > Configure field

Field types

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 field type

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 field type

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.

Options from supertag field type

(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 field type

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 field type

Number fields accept numbers only. This enables calculations in table view and allows setting max. or min. values of digits.

Tana user field type

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 field type

URL fields store URLs/external links.

Email field type

Email fields store email addresses.

Checkbox field type

Checkbox fields show the field value as a checkbox toggle instead of a field you can write in. They output Yes/No values.

Field configurations


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.)

Auto-initialize to value from ancestor with this field

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.

Auto-initialize to ancestor with this supertag

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.

Auto-initialize to random node with this supertag

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.

Auto-initialize to current date

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.

Auto-initialize to date of ancestor day node

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.

Auto-initialize to current user

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.

Hide field

Minimizes the field when part of a supertag.

  • Never (default): Field is never hidden
  • When empty: Field is hidden when it has no value
  • When not empty: Field is hidden when it has a value
  • When value is default: Field is hidden when populated with template value from supertag
  • Always: Field is always hidden

AI-enhanced field

Adds optional AI assistance for filling in this field, based on the name, description and contents of the parent node.

Used in

  • [number of] nodes: indicates the number of nodes where this field is used. Clicking this will open a new search for all nodes with this field.
  • [number of] supertags: indicates the number of supertags that use this field in its template. Clicking this will expand the list of supertags.


You can delete the field from here.

Move to Schema

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.

Commands (in Advanced)

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.

Page size (in Advanced)

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.

System fields

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.

  • Date field: When dragging nodes onto a calendar view, Tana adds a field to the nodes to store the date/time information.
  • Due date field: More on that here

Field definition

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).

Fields used in Search Nodes

See Search nodes

Merging fields

See Merging duplicate nodes

Related release notes

  • improvedClicking a date field now opens the date picker automatically ()
  • fixedAuto-initialize functions on fields will no longer initialize the fields if the function does not return a value ()
  • infoWe've renamed 'Instance' fields to 'Options from supertag' ()
  • infoField type "User" will now be called "Tana User" ()
  • improvedWe've cleaned up the system fields a bit, adding descriptions to all of them. They are now under a submenu when doing "Add field". We've also renamed a few: Node -> Node name, Description -> Node description, Owner -> Owner node. All existing setups will continue to work. ()
  • improvedWe no longer show "Create ..." when editing a field, but only use the autocompleter to suggest existing fields. ()
  • fixedWe fixed a bug with CJK input in fields. ()
  • improvedWe now show fitting placeholders for empty fields. 'Select Option' for Options, 'Add date' for Date, etc. This should make it easier for you to get over your blank field syndrome. ()
  • fixedWe fixed field options dropdown sometimes not being responsive to typing. You can now choose options fast as lightning ⚡️ ()
  • fixedFix for autocompleter sometimes not working correctly in fields. ()
  • fixedFix for autocomplete in user fields ()
  • fixedWe no longer show AI-suggested fields in field autocompleter ()
  • improvedWe now indicate on hidden fields whether they have content or not, and when they are AI processing. ()
  • newNew system field "Date from calendar node", works also for nodes placed under week, month and year nodes. ${sys:dateFromCalendarNode} in title expressions (but old ${sys:dateFromDayNode still works) ()
  • improvedSystem nodes and fields no longer have the purple colour, they're read only and will be further changed to make them stick out less. ()

Related FAQs

  • How can I bulk set a value to fields?

    Select the nodes whose field you want to set. Enter the command line (Cmd/Ctrl+K) and type Set to see your options.

    The Set [field] command only works on field types Option, Instance, Tana User and Checkbox.

  • 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.

  • In the command line, Set [field] -> [value] doesn't show all my fields, why?

    Set [field] command only works on field types Option, Instance, User and Checkbox.