Kuovonne's Guide to Airtable

Explore

Kuovonne's Guide to Airtable

Kuovonne's Guide to Airtable

Fields

Naming fields

⁠

⁠ Tip Jar ⁠ Thank Kuovonne for creating this content! ⁠ ⁠ ⁠

⁠

General guidelines

Use singular or plural names based on whether or on the field can hold only one value or multiple values.

When creating a linked record field, always check the name of the inverse field in the linked table.

When changing the configuration of a field, always check to see if the name should be updated.

Use the same names for standard metadata fields across all tables.

Use consistent capitalization (title case vs sentence case) and traditional spacing for fields that users interact with.

For helper fields, indicate the purpose of the field. I also use field names that resemble programming variables (lowerCamelCase). (Or see if you can consolidate formula fields so that you do not need to have a named helper field.)

Fields can be named based on what they represent, where they are used, or how they are calculated. What the field represents is usually the best choice. However, you may occasionally need to include information about where the field is used or how it is calculated.

Things to avoid

Avoid using all caps in field names.

Avoid including the field type in the field name.

Avoid using special characters in the field name to indicate if a field is required.

Avoid using quotes, commas, and periods in field names. (Your mileage may vary. I avoid things because I have custom scripts that require entering lists of field names as a single line of text.)

Field type specific guidelines

Linked record fields

Name linked record fields based on the table that is linked. Pay particular attention to the singular versus plural guideline.

If there are multiple links between two tables, include the relationship type in the field names. If there are two links between two tables, there will be four fields to name!

Number fields

If the units are not clear from the context, add them to the field name: {Length (in.)}

Lookup fields

Have the field name clearly indicate both the source field and the source table. For example, the lookup of the {Name} field from the [Projects] table should be Project Name, Name of Project, or Name (from Project), and not simply Name.

Date/Time fields

Have the name of the field reflect whether a time is included. For example, a {Date} field should not have a time, but a {timestamp} field should.

For a Created time field, include the word time (or date) to differentiate the field from a Created by field. Do not name a field simply Created.

If a Last modified time field watches the entire record, simply name it Last modified time.

If a Last modified time field watches only some fields, include the watched field name or group of fields.

Misc conventions

I don’t use these conventions, but some people find them helpful.

Use an emoji such as ⚙️ to indicate helper fields.

Use an emoji such as ⚡ to indicate if a field is used in an automation.

Temporary fields

Even temporary fields should have meaningful names.

Do not use default names for temporary fields unless you are 100% sure that you will delete the field within a few minutes during the same session.

If the temporary field will last longer than a few minutes, include your name and the date in the field name so that you and others can easily see context for the field.

It is okay to have super long names in temporary fields. Better to know what the field is for if it hangs around longer than you expected.

Will changing a field name break things?

Things that won’t break

Formulas (in formula or rollup fields) that reference the field. (But changing names of select choices in a field could break formulas!)

Conditions in lookup, rollup, and count fields.

View settings, including filters.

Native Airtable automations where you select the field by clicking.

Interfaces.

Most extensions provided by Airtable. See exceptions for scripts and Page Designer.

Things that might break

Scripts might break depending on how they are written. Scripts with hard-coded field names will break. Extension scripts that use script settings for all fields will not break.

Page Designer extensions might break, depending on whether the field is included as an element or if the field name is included in curly braces in a text element.

Third party integrations might break, depending on whether they reference fields by name or id

Third party extensions might break, depending on how the extension is written.

Suspicious field names

Copy at the end of a field name usually indicates that a field was created by duplicating an existing field, and then not renamed.

Calculation is the default name for a formula field.

Unusual situations

Normally it is not possible to have multiple fields with the same name. However, I have see a base where this happened. If you end up in this situation, rename the fields to be unique (or delete any unnecessary fields).

Normally it is not possible to have field names with leading or trailing spaces. However, I have seen this happen. If you end up in this situation, rename the fields to remove the extra spaces.

⁠

⁠ ⁠ Thank Kuovonne for creating this content! ⁠ Give Kuovonne a sandwich ⁠ Signup for Coda w/ referral link ⁠ ⁠ ⁠Buy from my Gumroad Store ⁠ ⁠ ⁠ ⁠ ⁠

⁠

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.