. These record templates allow you to create new records with preset values, and also apply those values to existing records.
Pros:
This system is native to Airtable.
This system may receive additional development to become more robust.
You can easily see all the templates in a base in one place.
You can apply a template without using an automation or a script.
Cons:
A template cannot link to an existing record. (A template can create a new linked record.)
You cannot use calculated values in the template (such as the current date).
Only people with creator permissions can create and modify templates.
The end result when applying a template can be confusing. Fields that have values when the template is applied sometimes retain their previous values and sometimes have the template values appended to the previous values, depending on the field type.
The initial version is not integrated with the built in “Show Dependencies” system.
Template defined in automation actions
You can use automations to set predefined values for a record, either by having the automation create the record, or by using a “when record created” trigger.
This method is different from using an automation to apply a template stored elsewhere because the actual values are stored in the automation itself.
Pros:
You can link to existing record.
You can control whether new field values replace or append to existing values in attachment fields, multiple selects, linked record fields, etc.
You can include calculated results as values, either by referencing formula fields in the triggering record or by using scripting.
Fields set directly using the “create record” or “update record” are automatically included in the “Show Dependencies” feature.
Cons:
Applying a template requires an automation.
You cannot reuse the template in multiple places.
It can be hard to search through all the automations in a base to identify the ones that act as templates.
Setting individual field values can be tedious, and you cannot easily re-arrange the order of fields.
Each base has a limited number of automations.
Dedicated Template table
Have a dedicated table for template records. Use automations or scripting to create new records or edit existing ones based on the template.
Pros:
It is easy to view and identify templates.
You can control whether new field values replace or append to existing values in attachment fields, multiple selects, linked record fields, etc.
You can include calculated results as values by copying the result of a formula field to an editable field.
Users can create templates with only editor permissions, or the table can be locked down to only let specific people create or edit templates.
Cons:
Applying a template requires an automation or a script.
Schema changes to the main table need to be mirrored in the template table.
Having links between tables requires additional linked record fields that can make the schema messy.
This system takes an additional table to maintain.
Template records in the same table as actual data records
Instead of having a dedicated template table, include the template records in the main table itself. Have a single select field (or similar) to identify which records are templates. Use an automation or a script to create new records or edit existing ones based on the template.
This is currently my favorite method.
Pros:
With no additional tables, schema changes occur in only one place.
People with edit permissions can create and edit templates.
It is easy to see templates in a dedicated view.
You can control whether new field values replace or append to existing values in attachment fields, multiple selects, linked record fields, etc.
You can include calculated results as values by copying the result of a formula field to an editable field.
Cons:
Applying a template requires an automation or a script.
Having to filtering out template records when viewing actual data can be annoying.
You cannot prevent editors with base access from editing existing templates. (You can prevent them from creating new templates.)
A combination of methods
You can combine techniques from multiple methods. For example, you could have an automation that creates a record using a native Airtable template for non-calculated fields followed by an update record action that updates other fields.
Note however that this spits up the logic in multiple places which can make the system more difficult to maintain.
Applying a non-native record template
When applying a template from a dedicated template table or template in the target table itself, you can choose between a create record action, update record action, or a scripting action.
Create record or update record actions work best when there are only a handful of fields with values in the template. If you want to include a new field in the template, you must add the field to the automation. If you delete a field from the template, you must remove it from the automation.
Scripting actions work best if you want to include all of the editable fields in the template, including any future fields. A script can be written to copy the values from all editable fields, including any future fields so that you can add or delete fields without having to touch the script or the automation. On the other hand, if you will copy over only a few fields and hardcode the names of the fields, the script will break of someone renames a field. (Using field IDs can avoid problems with renaming fields, but introduces other issues related to maintainability and portability.)
Templates versus default values
Some fields, such as number and single select fields, can be configured with default values. This is different from templates because templates typically have a combination of values for multiple fields, whereas a default value applies only to a single field.
When creating a record with a template, the template value is used instead of the default value.