[00:00:13]
Dan Fellars: Hey everyone, welcome back to the BuiltOnAir Podcast.
[00:00:17]
Dan Fellars: This is the second episode of our DevOps series where we’re looking at the admin side of running your business on Airtable and keeping it production ready.
[00:00:26]
Dan Fellars: So today’s topic is one I think every Airtable builder has been burned by at least once.
[00:00:32]
Dan Fellars: In Airtable, it’s that production is pretty much the only environment.
[00:00:36]
Dan Fellars: There isn’t really a true staging environment that you can rely on.
[00:00:40]
Dan Fellars: So when you rename a field or change in automation, it’s live the moment that you hit save for everyone using that base.
[00:00:47]
Dan Fellars: So what are we gonna do about it?
[00:00:49]
Dan Fellars: Most of the time that’s great.
[00:00:51]
Dan Fellars: It’s why Airtable feels so fast to build in, but when a change breaks something, you may not even be aware of the ramifications of it before it’s too late.
[00:01:01]
Dan Fellars: So let’s break this down into three questions that we’re gonna cover in today’s episode.
[00:01:07]
Dan Fellars: First, before you touch a field, what depends on it?
[00:01:11]
Dan Fellars: Second, where can you test a change that isn’t in production?
[00:01:17]
Dan Fellars: And third, when something does break, how will you know before your clients tell you?
[00:01:22]
Dan Fellars: So for this one, I’ve built a base Uh for client onboarding.
[00:01:28]
Dan Fellars: It includes a client’s table, a teams table, an onboarding task table.
[00:01:32]
Dan Fellars: Then there’s a formula that reads the client status, and an automation that sends a welcome when a client moves to onboarding.
[00:01:40]
Dan Fellars: And then there’s an interface page that shows the pipeline.
[00:01:43]
Dan Fellars: So all of it hangs of this one field called status that we’re gonna use today for our example.
[00:01:50]
Dan Fellars: Let’s start with the field itself.
[00:01:52]
Dan Fellars: So if you right click on the header, near the bottom of that menu there’s an option a lot of people have never clicked.
[00:01:58]
Dan Fellars: It’s the show dependencies option here.
[00:02:02]
Dan Fellars: And here’s where it tells you what is using this field.
[00:02:06]
Dan Fellars: So here we see that four things are using the status field.
[00:02:11]
Dan Fellars: Two automations, two elements on the interface page, and the health formula.
[00:02:15]
Dan Fellars: So that’s really useful, and I’d make a habit of checking this before you rename or delete anything in your bases.
[00:02:22]
Dan Fellars: Always check the dependencies.
[00:02:24]
Dan Fellars: But when noti notice what’s not what’s not here, what you can’t see.
[00:02:28]
Dan Fellars: It only knows about things inside this base.
[00:02:30]
Dan Fellars: So if you’re using Zapier or Make or even a sync to another base or a script somebody runs off their laptop, none of that shows up here.
[00:02:38]
Dan Fellars: And even for the automation, it does list, it doesn’t tell you how that automation is used, or even provide a link to the automation to help you out.
[00:02:47]
Dan Fellars: So now let’s do a rename of the field.
[00:02:49]
Dan Fellars: So I’m gonna change the status name to stage.
[00:02:53]
Dan Fellars: In this one field and one click to save it.
[00:02:55]
Dan Fellars: There’s a confirmation step that will show you the basic dependencies, but if you agree it goes live.
[00:03:02]
Dan Fellars: So here’s the good new good news, the formula updates itself.
[00:03:06]
Dan Fellars: It now reads as stage.
[00:03:08]
Dan Fellars: And the automation trigger updates too, and now it says if stage is onboarding.
[00:03:12]
Dan Fellars: So Airtable stores those by the field’s ID, not its name, so they follow the rename automatically.
[00:03:18]
Dan Fellars: The interface will do the same.
[00:03:20]
Dan Fellars: One more thing to watch out while you’re in this field, it’s easy to miss.
[00:03:24]
Dan Fellars: It’s not just the field’s name, the health formula compares status to the text of each option.
[00:03:30]
Dan Fellars: Either active, onboarding, pause.
[00:03:32]
Dan Fellars: So if someone renames the onboarding option in the dropdown, say to kick off, then the formula doesn’t throw an error.
[00:03:39]
Dan Fellars: It just stops matching and every client that was in onboarding quietly will show is not started.
[00:03:46]
Dan Fellars: So treat the options in a single or multi-select as part of the field and check what compares against them before you rename one, especially in the formulas.
[00:03:55]
Dan Fellars: So next time a client moves to onboarding, the automation ran and the script step failed.
[00:04:01]
Dan Fellars: It said no matching status found in table client.
[00:04:05]
Dan Fellars: That’s because the script looks the field up by its name, the way a lot of scripts do, and that name doesn’t exist anymore.
[00:04:12]
Dan Fellars: And it’s the same for anything outside Airtable that reads by field name.
[00:04:16]
Dan Fellars: So some integrations might use the ID, but a lot will use the name.
[00:04:21]
Dan Fellars: And you don’t find out about that until it breaks.
[00:04:23]
Dan Fellars: So inside Airtable you can avoid this one.
[00:04:26]
Dan Fellars: In the script step, clip the plus on an input value, choose base structure, and pick the field.
[00:04:32]
Dan Fellars: This gives you the field’s ID instead of the name, and you read the field by that ID.
[00:04:36]
Dan Fellars: An ID doesn’t change when someone renames the field, so the script will continue working.
[00:04:41]
Dan Fellars: I highly recommend using that approach.
[00:04:44]
Dan Fellars: And one more thing, that trigger change from status to stage, but the automation’s own revision history still shows one entry the day it was built.
[00:04:54]
Dan Fellars: So nowhere anywhere do when we rename the field or when.
[00:04:57]
Dan Fellars: So the record history only covers your data, it doesn’t cover your structure.
[00:05:02]
Dan Fellars: So where do you test a change like that?
[00:05:04]
Dan Fellars: The first habit, and we talked about this in our last episode, is taking a snapshot before you make the change.
[00:05:10]
Dan Fellars: In your base history, go to snapshots and take a snapshot.
[00:05:14]
Dan Fellars: I wish that I could rename this and say like before status rename, but unfortunately you can’t.
[00:05:20]
Dan Fellars: There’s no naming of the snapshots.
[00:05:22]
Dan Fellars: You just get a timestamp.
[00:05:24]
Dan Fellars: And when you take one, you can’t take one for a while.
[00:05:27]
Dan Fellars: So if you’re gonna rely on snapshots before these risky changes, you need to keep note of when you did it and and remember the timestamp.
[00:05:36]
Dan Fellars: So the X second option is to duplicate the base and try the change there.
[00:05:40]
Dan Fellars: You can bring the records and the comments along.
[00:05:43]
Dan Fellars: The revision history doesn’t come with it.
[00:05:45]
Dan Fellars: A third option that we haven’t talked about yet is the app sandbox.
[00:05:50]
Dan Fellars: If you’re on a plan that has it, this is the one I’d look at for a lot of changes.
[00:05:56]
Dan Fellars: If you go to the base name, uh in that menu, there’s a create sandbox.
[00:06:01]
Dan Fellars: And you can now switch between product and sandbox mode.
[00:06:05]
Dan Fellars: And the first thing it tells you is configuration changes are now locked in production.
[00:06:09]
Dan Fellars: So I want to spend a minute on that because it’s a concept I don’t see a lot of people using.
[00:06:14]
Dan Fellars: It does require a business plan or hire, so it’s not available on all plans.
[00:06:19]
Dan Fellars: While the sandbox exists, production is locked for structure.
[00:06:23]
Dan Fellars: Your team doesn’t notice, they keep editing.
[00:06:25]
Dan Fellars: Records, the automation keeps running, and interfaces work as expected.
[00:06:29]
Dan Fellars: But nobody can rename a field in production or change an automation or edit an interface.
[00:06:35]
Dan Fellars: Not even the admin.
[00:06:37]
Dan Fellars: So it will then send you to the sandbox for that.
[00:06:41]
Dan Fellars: So that’s the part I like.
[00:06:42]
Dan Fellars: It forces the builder to not perform live updates in production.
[00:06:45]
Dan Fellars: Every structure change has to go through the sandbox.
[00:06:49]
Dan Fellars: On the flip side, record edits that you make in the sandbox stay there, so only structure goes between sandbox back into production.
[00:06:57]
Dan Fellars: So let’s look in the sandbox.
[00:06:59]
Dan Fellars: If I rename the stage back to status, that will fix the script that was using the name.
[00:07:04]
Dan Fellars: And then I added a new a new field as well.
[00:07:08]
Dan Fellars: This is something I wish was exposed in all bases.
[00:07:12]
Dan Fellars: It shows you the structural changes that you make.
[00:07:15]
Dan Fellars: In the top, it will say it will take a snapshot before it applies them back.
[00:07:20]
Dan Fellars: So you hit apply and now the changes are go back into production.
[00:07:24]
Dan Fellars: And if I look at the snapshots, there’s one it took for me, right next to the one I took earlier.
[00:07:29]
Dan Fellars: So both just say how long ago.
[00:07:32]
Dan Fellars: But remember you don’t know which one is which, so you gotta keep that uh in memory or keep a note of that.
[00:07:38]
Dan Fellars: So once you’ve got your sandbox, there’s two ways out.
[00:07:41]
Dan Fellars: The first is to sync it back, like we showed, you review the changes, pick what you want, and apply it.
[00:07:47]
Dan Fellars: But notice the sandbox doesn’t go away when you do that.
[00:07:50]
Dan Fellars: It’s still there and production is still locked.
[00:07:53]
Dan Fellars: Which is fine if you’ve got more changes to come.
[00:07:56]
Dan Fellars: The second approach is you can cut it off.
[00:07:58]
Dan Fellars: So if you go to your base name, click the three dots next to the sandbox and click delete sandbox, confirm it, now your production goes back to being a normal base and you can make changes directly in it again.
[00:08:10]
Dan Fellars: Just know that anything you didn’t apply in the sandbox goes to the trash.
[00:08:15]
Dan Fellars: And it only comes back um in as the separate base and not in your sandbox.
[00:08:20]
Dan Fellars: So here’s how I’d actually use it.
[00:08:22]
Dan Fellars: If you have something risky coming up, Create a sandbox which will lock your production, make the change in the sandbox, then apply just what you want and deploy it back into production and then delete your sandbox.
[00:08:35]
Dan Fellars: Then you can use production again for all the small minor stuff that you might be doing.
[00:08:39]
Dan Fellars: Next time there’s a risky change, you go back to the sandbox, create a new one, and do it all over again.
[00:08:45]
Dan Fellars: So so far everything has been about one base, but a lot of times you don’t have just one base.
[00:08:51]
Dan Fellars: You have the same base and you need to multiply it, copy it ten times with maybe slight variations.
[00:08:56]
Dan Fellars: Like one per region, one base per team, and then a rename, you have to do that ten times across all of them.
[00:09:04]
Dan Fellars: And by the third or fourth time, you’re quite you’re asking if there’s a better way.
[00:09:08]
Dan Fellars: And that’s where managed app and managed components come in.
[00:09:11]
Dan Fellars: You can find these within the account settings under Builders Hub.
[00:09:16]
Dan Fellars: And then you build in a development base and your team doesn’t work in that one.
[00:09:21]
Dan Fellars: You then publish it and then it becomes available to install into any base, and those base become the child bases of the managed component.
[00:09:29]
Dan Fellars: So there’s two flavors and they behave differently.
[00:09:32]
Dan Fellars: A managed app is the whole thing.
[00:09:34]
Dan Fellars: The base, the interfaces, the automations, a complete workflow.
[00:09:37]
Dan Fellars: It installs as a brand new base.
[00:09:39]
Dan Fellars: You can’t add a managed app to a base that you already have.
[00:09:43]
Dan Fellars: A managed component, on the other hand, is just one piece.
[00:09:46]
Dan Fellars: piece, which can be a few tables plus their automations and interfaces.
[00:09:50]
Dan Fellars: It doesn’t need to be an entire base.
[00:09:52]
Dan Fellars: And that you can drop into existing bases.
[00:09:55]
Dan Fellars: So if your team already has existing bases and but they just need a a managed component of a few bases, you can roll that out in that manner.
[00:10:05]
Dan Fellars: So I typically go this route of using a managed component instead of a manag, so that you can apply it into existing ones and just what you need.
[00:10:14]
Dan Fellars: A managed component gets the benefit of both, so I prefer that.
[00:10:18]
Dan Fellars: So roll out a change works like this.
[00:10:20]
Dan Fellars: You make the change in the development base, then you publish, then each child base can update when it’s ready.
[00:10:27]
Dan Fellars: Or if you need everyone on the new version, you push the update and you get confirm update or force push updates.
[00:10:34]
Dan Fellars: But be careful with the force push because it can’t show you what it’s about to change first.
[00:10:39]
Dan Fellars: Either way, it does take a snapshot of eSpace before it updates, and record data never travels, so only the structure.
[00:10:47]
Dan Fellars: And in the child bases, the manage parts are locked.
[00:10:50]
Dan Fellars: They’re tagged manage by your org.
[00:10:52]
Dan Fellars: So nobody can rename them, delete them, or change their structure locally.
[00:10:56]
Dan Fellars: Changes only flow one way from the development base down to the children bases.
[00:11:01]
Dan Fellars: So what each base does keeps in its local settings, turning automations on or off, or credentials.
[00:11:08]
Dan Fellars: or who gets notified or interface filters, they can still add their own tables and fields around the managed ones.
[00:11:15]
Dan Fellars: But if a local setting conflict with an update, the local settings will win.
[00:11:19]
Dan Fellars: So you gotta be careful about that.
[00:11:21]
Dan Fellars: It might bite you.
[00:11:22]
Dan Fellars: So how does this compare to sandboxes?
[00:11:24]
Dan Fellars: So a sandbox is only for one single base.
[00:11:28]
Dan Fellars: Managed items cover multiple bases they’re installed in.
[00:11:31]
Dan Fellars: So when you change a uh sandbox, it will go directly to that one base and it will lock your production structure until you delete the sandbox.
[00:11:41]
Dan Fellars: Managed items just lock the managed component, so allows you to still do more within that base.
[00:11:50]
Dan Fellars: But it’s you ki you can unpublish it, but once you unpublish the manage component, there’s no going back like you can do with sandboxes.
[00:11:58]
Dan Fellars: So you gotta be careful that when you unpublish something.
[00:12:02]
Dan Fellars: So which one really depends on what you need.
[00:12:04]
Dan Fellars: If it’s a risky change for one time on single base, you use a sandbox.
[00:12:09]
Dan Fellars: And you can throw it away if it’s wrong.
[00:12:13]
Dan Fellars: So it’s a lower cost approach to making changes.
[00:12:17]
Dan Fellars: And if you have the same thing in many bases, that’s where you need to go the manage route.
[00:12:23]
Dan Fellars: You change it once and every base will stay identical.
[00:12:26]
Dan Fellars: The cost is you have to plan it up front and you lose some functionality, especially if you’re using sync views, which we won’t get into today.
[00:12:34]
Dan Fellars: But any change you want to make always goes through the development first and requires a Publish and pull cycle across all child bases.
[00:12:41]
Dan Fellars: It’s a massive time saver versus the alternative of having to update the same functionality across a large number of similar bases.
[00:12:50]
Dan Fellars: So okay, last question.
[00:12:51]
Dan Fellars: When something breaks, how do you find out?
[00:12:54]
Dan Fellars: For automations, it’s common that they will fail from time to time.
[00:12:58]
Dan Fellars: So in the automations under the history, you’ll see a red failed item and you can filter to see the failed ones.
[00:13:05]
Dan Fellars: And it’s often not noticeable from the front end data layer or interfaces.
[00:13:09]
Dan Fellars: So fortunately, Airtable does send an email on automation failure.
[00:13:13]
Dan Fellars: But the question is who gets it.
[00:13:15]
Dan Fellars: Recently, thankfully, they added the ability for every automation to have unique subscribers.
[00:13:20]
Dan Fellars: And by default, whoever built it is the default uh receiver.
[00:13:25]
Dan Fellars: So if they that if that person leaves the company, then things start to get messed up.
[00:13:30]
Dan Fellars: That’s why I recommend having a uh a shared inbox and using that to um to be able to go and have a central place where all your automations go.
[00:13:45]
Dan Fellars: It’s very helpful.
[00:13:46]
Dan Fellars: You can also send to Slack as well.
[00:13:49]
Dan Fellars: So once you fix the root cause, you don’t have to recreate the event if it’s in the data layer.
[00:13:54]
Dan Fellars: But if it’s a structural problem, a retry won’t pick up the newly modified automation steps, unfortunately.
[00:14:00]
Dan Fellars: So rerunning will you will use the previous version of ease step.
[00:14:04]
Dan Fellars: Instead, you need to re-trigger the automation to confirm it works.
[00:14:09]
Dan Fellars: So renaming isn’t really the problem.
[00:14:12]
Dan Fellars: Renaming of fields and things like that is pretty normal.
[00:14:15]
Dan Fellars: And usually the problem is when you find out later that that something is messed up.
[00:14:20]
Dan Fellars: So highly recommend using sandboxes or managed components in your bases, and that will help you work in a production environment.
[00:14:33]
Dan Fellars: and make sure that you avoid these critical mistakes.
[00:14:36]
Dan Fellars: So next time we’re gonna be talking about access control and who has access to what and look forward to that.
[00:14:42]
Dan Fellars: If you haven’t already join our community.
[00:14:44]
Dan Fellars: If you have a story about how working in production has has uh bit you and what you’ve done to overcome it, let me know in the comments.
[00:14:52]
Dan Fellars: Reach out in our community.
[00:14:53]
Dan Fellars: I’d love to hear from you.
[00:14:55]
Dan Fellars: Until then.
[00:14:56]
Dan Fellars: We’ll see you next time on the BuiltOnAir Podcast.