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 = Add 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 Outline and navigation views, fields are only visible when the node is expanded, but can be added to Display in view options. In Table view, fields appear as columns. 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.

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

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.

Auto-initialize to ancestor with this supertag

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.

Auto-initialize to random node with this supertag

Only available on Options from supertag fields. Grabs a reference to one or more random nodes with this supertag.

  • Example: You could have #Journaling prompt and have three show up in a "Today's Prompts" field in your #Journal nodes.

Auto-initialize to current date

Only available on Date fields. 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

Only available on Date fields. 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.

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.

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

Audio-enabled field

When enabled, you will see a button wherever this field is used, which will let you use realtime transcription to fill in the field.

You can optionally configure a command to run when the transcription is done.

AI instructions

Plain text instructions for the AI when filling this field from voice memo processing or the autofill command.

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.

Make it discoverable

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

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.

Field has semantic function (in Advanced)

Shows for Options and Options from supertag field types.

Semantics give meaning to node relationships, and is a core concept that makes Tana powerful. Currently, semantic functions are an experimental feature in Tana.

There are usually two distinct aspects of using semantic structure: creating the structure, and running searches using the structure.

There are many different types of semantics, such as "is a", "has a", "related to", "part of" among others.

Tana has many semantic functions already baked in. Supertags express "is a" relationships, Fields express "has a" relationships with the node (and to be even more confusing, fields can also express is a/has a/state/description, expressed in human language which is not something Tana can innately understand), and the outline editor expresses a top-down hierarchy with more detail the deeper you go.

Tana offers "Part of" semantic functions as an advanced, experimental feature.

Part of

  • The semantic function Part of arranges information in a strict tree hierarchy, for breakdown/drill-downs. Example: An engine is part of a car. Genesis is part of the Old Testament. Oslo is part of Norway.
  • The Part of structure is a "one-to-many" relationship. Things can only be part of one other thing, no more. Example: A task that can belong to two projects would not be a valid "parts of" relationship. Another example: one engine can have many parts, but the parts can only belong to one engine.
  • Part of relationships become useful when you want to look for things that are related to parts of this structure you've created. For this we use the field operator COMPONENTS REC, meaning that you're searching components recursively based on the field value.
    • Example: When the Tana team reviews feature ideas, we've mapped our features and their parts into a part of semantic structure so you can attach feature requests to very small parts of the product like "extend tag". When a team member in the future reviews feature ideas for "supertags", it will return all feature requests related to supertags and any part associated with it through part of, including extend tag and more. This allows us to do data entry at very granular scales, and retrieve data at any scale that fits the need/goal.
  • COMPONENTS REC is an expensive search so using it for large mappings may slow down your Tana experience. We plan to improve this in the future.

To give a field semantic function

  • In the field configuration, ensure the field type is set to Options from supertag
  • Go to Advanced and toggle on Field has Semantic function

How to connect two nodes with a Part of relationship

  • Create a field (let's call it is part of) with semantic function toggled on and Part of selected
  • If you want to relate Engine to be a part of a Car, add the is part of field to the Engine node, and put Car as the field value.

How to use information that is semantically connected with Part of

We will use an example to demonstrate how this works.

1️⃣ Use the semantically connected data as field values

  • Let's say we are a mechanic and need to catalog every component that exists in a car so we can keep track of inventory. We have tagged every component with something like #Car part, and this supertag also has a field with semantic function Part of, where each component is mapped as part of a larger component.
  • We have an #Inventory supertag with an instance field called Related car part that pulls options from #Car part, and another field called Stock status where you record inventory stocks.

2️⃣ Query your inventory using the semantically connected data

  • You're at the engine parts store and need to know which engine parts your shop is low on. You look for all #Inventory where >Stock status: Low, and >COMPONENTS REC: Engine. This retrieves inventory items with low stock, for any car component that is part of the Engine.

Examples of common part of relationships

Common traits is that the parts have undisputed singular relationships to their whole.

  • Budgets (company budget > department budget > project budget)
  • Organizational structure (corporation > division > department)
  • Scientific classification (plant kingdom > ericaceae family > blueberries)
  • Addresses (Canada > Ontario > Toronto)

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.

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.

Fields used in Search Nodes

See Search nodes

Merging fields

See Merging duplicate nodes

Related articles

More articles