Skip to content
Tana Logo

Fields

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.

Overview

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.

Basics

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

Documentation

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

Auto-initialize

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.

Required

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.

Delete

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

  • improvedAfter a lot of community feedback regarding recent changes we made to field availability in autocompleter based on where they lived, now letting you also retrieve fields that are owned by other supertag templates in field auto-completer ()
  • fixedWe fixed a bug where numbers in fixed options, in options fields, were inserted as plain values, not references. ()
  • 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" ()

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.

    Related docs:

  • How do I bulk delete a field and its values?

    In order to bulk-delete fields and their values, they need to:

    1. be in Table view, and
    2. not part of a supertag template.

    Here's how you do it:

    If you know the field you're targeting but do not have a list of nodes with the field already:

    • Use the field definition in a search node to find all nodes with this field.

    With the list of nodes that have the field and values you want to delete:

    • View as table
    • Display that field as a column
    • Right-click header > Delete column and values

    Related docs:

  • How do I set up relationships between nodes?

    There are two main ways to create a connection between one node and another:

    References/inline references

    Use references or inline references to create an unstructured two-way connection between the nodes and the place you mention them in.

    The reference section shows you all unstructured mentions under "Referenced in..."

    Fields

    Fields and their field values create structured two-way connection between nodes. Structured in the sense that the connection is labeled via the name of the field.

    • Example: A book node has a field called Author, where you can enter a reference to any person. The relationship between the book and the person is that they are the Author.

    Fields offer a variety of ways to create structured connections:

    • Create a Plain field and copy/paste or @-mention any node into it
    • Create an Options field where you can choose from a list of your choice
    • Create a Supertag from Options field where you can choose from a list of all nodes tagged a chosen supertag.

    Fields show up in the Reference section as "Appears as [field name] in..."

    This screenshot demonstrates how the different connections show up in the Reference section of a node:

    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:

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

    Related docs:

  • Should I use the DUE DATE field?

    TL;DR: No, create your own date fields.

    Background: Early on in Tana's history the team wanted a way to find overdue tasks but there was no current way of searching for nodes with dates relative to a certain date. So, the system field "Due Date" along with the search operator OVERDUE was created specifically this reason.

    But since the introduction of LT / GT (less than/greater than) operators, there is no reason to use the system Due Date field, along with the OVERDUE search operator.

    A user defined field for Date or Due Date offers more flexibility:

    • You can use initialize feature if desired
    • Consistent color with other fields
    • You can hide the field

    Example of a query to find nodes with a date that is past a certain time:

    Source of FAQ: Tana Community Resource Hub

    Related docs:

  • What does the system field "Number of nodes with this tag" do?

    This system field is relevant only for supertag objects, and reveals the number of times a tag has been used.

    How to use it:

    • Make a search node with IS TAG - which will find all supertags in your graph
    • Display: Number of nodes with this tag

    It shows you how many nodes the tags have been applied to.

    Related docs:

  • What does this warning mean: "Fields nested under other nodes or fields will not work as expected"?

    This warning pops up in the supertag template when there are fields that are indented (another word for nested).

    There are several "expected" behaviours of fields in supertags that only work when they are first-level nodes in the template, such as (and not limited by) the following:

    • Searching for nodes based on their field values (all #tasks with Status::Complete)
    • Viewing the node as a table, with fields as columns
    • Using fields to build title using title expressions

    If you do not care for any of the above uses, you can safely ignore the warning.

    Related docs:

  • Why is my field not auto-initializing?

    How auto-initialization works

    There could be several reasons why a field isn't auto-initializing.

    Currently, field auto-initialization is triggered only on the event where

    • a supertag is applied to a node, and
    • the field is in a placeholder state (i.e. doesn't exist/have its own nodeID).

    Fields will therefore not auto-initialize under the following events:

    • 1. When added anywhere as a solo field
    • 2. On nodes where the supertag is already applied and the field is added after the fact
    • 3. If the field is nested under a node in the supertag template. Fields have to be direct children to the supertag to auto-initialize

    The next question is likely: can I trigger auto-initialization somehow?

    As a result of how initialization is triggered today, there is an unintentional quirk that can be used to re-initialize fields.

    For fields that fall under category 2 (from the list above), it is possible to trigger initialization by applying any supertag to the node. The fields have to be in a placeholder state, or it won't work. Video demo:

    Related docs:

Related articles

See all