Help

How can I update the record in another table if condition is matched?

Topic Labels: Automations
Solved
Jump to Solution
2361 8
cancel
Showing results for 
Search instead for 
Did you mean: 
mshah72
6 - Interface Innovator
6 - Interface Innovator

I want to update certain values (columns) of a record automatically in another table if it meets the condition. How can I do so?

I have added a checkbox in Table 1. If the check box in Table 1 is checked, then update the values in Table 2.

1 Solution

Accepted Solutions

Views have no fewer capabilities for limiting who can access than Tables. In Airtable, visibility is either everything (all tables, all views) or nothing (you literally can’t open the base). Meaning, just because you put “Department B’s records” in another table doesn’t mean they are prevented from looking at Table 1 anyway.

Accessibility in terms of editing is controlled based on the field. For both Tables and Views you can say “Only Department A can edit these fields, only Department B can edit these other fields”. Accessibility in terms of creating new records is controlled at the Table level.

So you could use one table and say “only people in Department A can create new records. Only people in Department B could edit the appropriate fields for the records already there”.

See Solution in Thread

8 Replies 8

That doesn’t sound specific enough. If Record A from Table 1 has a checkmark, update which records in Table 2? Every record? Are your records linked together?

I will try to elaborate it more.

There are multiple entries in my Table 1. I also have a column named Approved. There are some entries which will be Approved (checkbox is checked with a tick mark if approved). So now, if the entry which I entered now, is Approved, the I want to print its primary key and some other columns automatically in Table 2.

So records in Table 2 are the same as Table 1, except they are approved? Why not just use one table and filter your views based on the checkbox field?

It is a work flow. Department 1 (Table 1) approves and pushes the info to Department 2 (Table 2). Department 2 inputs some other information and pushes to Department 3 (Table 3). So I want a separate table for each department.

So I haven’t used the concept of filter.

Typically, it is advised that “The same info” be kept in one place, one table. Moving the same record into several tables adds many points of potential human error, plus you’re eating up limited Automation Runs you get per month.

Using filtered views, however, is how Airtable is designed to work in instances like these. Table 1 would have a view called “Department A” and would have a filter applied where the checkbox is empty and would only have the fields Department A needs to fill in visible. Once the checkbox is filled in it would be filtered out of that view automatically. Conversely, Department B would get their own view that is filtered to where the checkbox is filled and would have the additional columns visible.

So can each view be set accessible to particular department? If so, then this could be the best.

Views have no fewer capabilities for limiting who can access than Tables. In Airtable, visibility is either everything (all tables, all views) or nothing (you literally can’t open the base). Meaning, just because you put “Department B’s records” in another table doesn’t mean they are prevented from looking at Table 1 anyway.

Accessibility in terms of editing is controlled based on the field. For both Tables and Views you can say “Only Department A can edit these fields, only Department B can edit these other fields”. Accessibility in terms of creating new records is controlled at the Table level.

So you could use one table and say “only people in Department A can create new records. Only people in Department B could edit the appropriate fields for the records already there”.

@mshah72

In addition to all the excellent guidance that @Kamille_Parks gave you above, you might benefit greatly from taking my free Airtable training course, which covers the concept of views in depth: