Skip to content
When to create a new development base. Whenever starting a new major project, I create a fresh development base from the current production base. This ensures that I pick up any new changes that other people may have made. It also means that I do not have any leftover clutter from a previous development base, such as temporary fields that ended up not being necessary. Occasionally I will reuse a very recent development base when experimenting with very minor changes.Dev Base Name. I update the name of the development base to include “DEV” a the start of the name and the date it was duplicated at the end of the name. This makes it easier to identify which base is the development base and when it was created. Sometimes I include the specific project or purpose I am working on in the base name.Dev Base Color. I change the color of the development base to be a different shade from the production base. This makes it easier to tell at a glance if I am working in the development base versus production.Dev Base Workspace. I put development base in a different workspace from the production workspace. This hides it from regular users. Moving the base to a different workspace can sometimes affect base permissions, so I may need to also edit table and field permissions after creating the development base.Automations. All automations are turned off in the new duplicate base. Usually this is good because it prevents unnecessary automation runs. However, if some automations are necessary for the functioning of the base, they must be turned back on.Hardcoded IDs. All of the Airtable IDs for the base, tables, fields, records, and shared views are changed when the base is duplicated. If any of these IDs are hardcoded in formulas or scripts, they need to be changed.
Check dependencies. Use the native dependency checker to see what might be impacted by any fields that you are thinking of changing. Manually check extensions in dashboards, scripting actions in automations, and third-party integrations for dependencies, because they are not included in the dependency checker.Leverage existing fields. Before creating a new field, see if you can leverage an existing field.Rename fields. If you change how a field is used, consider renaming the field to better represent its new functionality. If you add a new field, check if any related existing fields need more specific names.Test, test, test. The best way to know if your changes work is to test them.
Third-party integrations. Depending on how your third-party integrations are setup, they might not work with your development base. You may need to make development versions of your third-party integration in order to test out the system. Synced tables. When you have multiple synced tables, the syncs can get complicated.
Timing. Plan on making the changes when they will not disrupt other people’s workflows, and when they will not impact any automations. Written plan. Having a written plan that lists the exact steps you need to perform in order makes the implementation go more smoothly. For example, you may need to create a field before updating an automation.Data changes. Changes to schema are often accompanied by data changes. If you have a new field, you may need to back-fill data for existing records. If you split or merge fields, you will need to split or merge the data for existing records. Include how you are going to migrate the data in your written plan so that you don’t accidentally delete data before it is migrated.Notifying users. If the changes will affect other users, tell them if they need to be off the system during a specific window of time. Also tell them what to expect and do differently once the changes are implemented.Testing. Include testing the changes in the production environment as part of the implementation. Sometimes things don’t work as expected when in the production environment. Test again to make sure that everything works properly.
Kuovonne's Guide to Airtable
- Pages
Share
Explore
Making major changes to a base
One of the advantages of Airtable is how quick and easy it is to make changes. However, when making major changes to an important base used by multiple people, you need to be careful and slow down to ensure that the changes have the intended results without breaking anything.
Create a development base
When making major changes to a base, you should make the changes in a development or test environment instead of the actual production base that everyone uses. For non-enterprise plans, there is no built-in support for development versus production environments, so you must manually create the development base (by duplicating the base) and then manually reproduce the changes in the production base.
Working in the development base
Tricky Situations
Copying changes to production
Thank Kuovonne for creating this content!
Publish date: 2024-09-10
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.