Deleting fields/tables/bases by accident

Airtable Questions
1

Hello everyone

I am looking for some reassurance on how to manage the risks associated with growing number of “Creators” in my base.

There would be a massive operational and financial cost if a key field, table or base was deleted by accident (or by a disgruntled employee).

“Interactive complexity” (multiple components interacting together e.g. here the links between fields/tables in the schema) and “tight coupling” (how close the dependencies are linked and the period of recovery e.g. filters are broken immediately when a field is deleted) means that there will inevitably be an accident over some period of time.

We manage this risk by having highly centralised control of who can be a Creator (only me currently).

When recovering in instances where a field is deleted, the options offered by Airtable don’t really help us:

  • Snapshots would only allow returning to an older version but in an entirely new base (thereby not recovering the original base and it’s links to other integrations).
  • Crtl z / back / Airtable restoration would return the deleted field but it would not restore the filters where that field was used and any views linked to automation triggers would have released the data. By that point all the automations would have been triggered (eg Make, zapier)

How does everyone else manage with many people working as creators in a base?

1 Like
2

Welcome to the community!

If possible, don’t let people get creator access to an important base unless they really need it and you can verify that they really know what they are doing. I think that every base should have at least two people with creator access (for backup purposes).

I like to give people creator access to a sandbox base or a playground base where they can test things out and see how things work, make mistakes, and recover in a safe environment. I also demonstrate how small changes can break systems and share stories of the headaches involved in recovering from accidental changes. I also encourage everyone to use a “personal sandbox view” for one-off creator-type activities. Then the changes are copied over to production views only after everything is tested.

I also use On2Air schemas to back up my schemas of important bases. I also periodically duplicate bases to have an easy way to look at old configurations.

I lock views that should not be messed with. I try to avoid triggering automations off of views and embed the conditions in the automation itself.

I also really like the Enterprise feature that shows the dependencies of a field and teach people to use that before making any changes to a field.

I try to design my Make integrations so that scenarios are not tied to a specific base but can work with any base that calls the webhook. This also makes testing the integration prior to putting it in production easier.

1 Like
3

Thanks so much for this @Kuovonne

On2air schema - I’ve never heard of this. Do you know someone there I could email ?

Thx again

4

@Hannah_Wiginton can hook you up.

1 Like
5

Hi @Hannah_Wiginton is this product still available to purchase?

6

Welcome to the community, @Bertie!

You are correct to be worried about these things. Particularly because Airtable makes it extremely difficult to piece things back together after restoring from a snapshot, since all of your record IDs (and other IDs) will be different in your backup.

So you might want to add an autonumber field to each table, so that you at least have a non-changing number to represent each record. I haven’t tested this myself yet, but this number should theoretically remain the same after a restoration of a backup.

But back to your key concerns:

You are correct that at the creator level, Airtable essentially gives full access to everything. It provides an environment that allows for accidental (or purposeful) destruction of everything: data, fields, views, automations, interfaces, etc.

So you are right to limit creator access to as few people as possible.

But even the editor level allows for accidental deletions of: (1) records, (2) views, (3) share links for forms & other public views, (4) syncable view share links for syncing, and more.

You can see some of the permissions listed on this page:

However, there are a couple of things that you can do to lock down some (but not all) of these things from editors:

  • You can lock down the creation of records in specific tables from specific editors.
  • You can lock down the deletion of records in specific tables from specific editors.
  • You can lock down the editing of specific fields from specific editors.
  • If you lock a view, editors cannot unlock those views.

You can learn more about field & table permissions here:

You might also want to start experimenting with Interface-only access to your base, where you only give editors access to a group of interfaces… but NO ACCESS to the rest of your base.

Interfaces are very limited by design, so it would be much more challenging for somebody to cause a catastrophic problem in your base, unless you specifically gave them that capability within the interface.

1 Like
7

And here is some information on sharing interfaces:
https://support.airtable.com/docs/interface-designer-permissions

8

Thanks @ScottWorld

The editor side of things is fine, we lock views and have custom permissions set up on all important fields and tables.

We use Airtable to run most of our company ops with a large team. Deleting a crucial linked record field would bring the company to its knees. It is normal for one person to control all schema changes to alleviate this risk? (I basically can’t go on holiday!)

Why is this issue not shouted about on the main community forum. It seems like such a big risk to anyone building in Airtable!

Thanks again for your advice.

9

Yes, it is normal in most database systems (not just Airtable) for only 1 or 2 trusted people to have access to schema changes.

Also, once your database is setup, schema changes should be pretty infrequent.

If you find that you can’t go on vacation because you keep making schema changes, then that could be a sign that your database isn’t finished being developed yet, or that your database was designed incorrectly. For example, lots of people try to use Airtable like a spreadsheet — where they keep adding columns for reporting purposes when they should be adding rows instead.

10

Yes, it is normal for only one or two people to control all schema changes in a team’s bases. Schema changes should be relatively rare. I agree with Scott that if you cannot go on holiday because of schema changes, your base probably needs a redesign to make the schema more stable.

Deleting fields should only be done by someone who knows what they are doing. Doubly so for deleting linked record fields because back link fields often look unimportant when they are vital to a system.

Community forums tend to react to questions that are posted.

11

Thanks. It’s interesting to know that it’s normal in a company for only 1 or 2 people to have schema access. I didn’t know that, thanks for the context.

We have been developing our base for 5 years now and have a number of automations running off it (c.500). It’s complex for sure but I’m confident we are using fields and tables in the right way.

The base is constantly developing to meet new business needs and data requirements. It’s one of the reasons we love Airtable - development and launch of a new project takes days rather than months. It has been the reason we have out-performed our competition who use salesforce.

Would be keen to book in a call with either of you if you consult?

12

HI @Bertie,

Yes, I am an Airtable consultant, and you can feel free to contact me through my website to setup a call: Airtable consulting — ScottWorld

1 Like
13

Hey @Bertie

We do have a free version of On2Air Schemas right now, but are limiting upgrades and new registrations.

We’re working on adding some of the features of On2Air Schemas to our On2Air Backups app.

Thanks so much,
Hannah

1 Like
14

Thanks for the shout-out @Kuovonne :sparkling_heart:

15

@Bertie - we do have our On2Air Forms app that allows you to create specific dashboards so you can limit who can access, create, or update records in Airtable.

Build a Dashboard using Airtable Data with On2Air Forms

Glad to help you get set up if interested.

16

@Hannah_Wiginton With the dashboard feature, I see that you can give a user a custom URL to edit their own record and edit linked records as well.

Is there a way to create a URL that just takes people directly to the “grid” view of all the linked records, without starting at that “parent record” first? In other words, just give people a link to go to all the children records? (I’m thinking of the grid editor in MiniExtensions.)

1 Like
17

@ScottWorld you can create a unique link to all the records in a grid view!

right now, it does use a linked table as the form source. But we have a match setting where you choose a single field to prefill and it displays an entire table with records that can be edited, created, deleted, or just viewed).

Here’s an example

The URL looks like this with the ?employees=Active as the prefill

https://on2air.com/form/5Xfc32?employees=Active

Here’s the tutorial

How to Display Records in a Table List

image
image1920×1135 162 KB

1 Like
18

Hi @Hannah_Wiginton when will you be opening registrations to the schema app?

19

Hey @Bertie you can still add the Schemas app to your base but we’re no longer allowing upgrades.

We’re currently focused on our On2Air Backups and On2Air Forms apps.

20

This is fantastic, @Hannah_Wiginton! Thanks so much! :smiley: :raised_hands:

1 Like