Update Records Airtable Base to Airtable Base w Integromat

[The_Redirection]

I have 2 different AT bases with the same information in both bases (columns are named the same and the general content of each record is the same). One is considered our main base (Base A) and the second is client-access views with no editing (Base B). I’d like to use Integromat or Zapier to update records in Base B as the records change in Base A.

Please advise. I’ve tried several attempts with Integromat and always come up with errors and incomplete functions.

Thank you!

[M_k]

Hi @The_Redirections_Gro

I wondered if you could provide screenshots of your Integromat scenario and the errors that are showing.

This way we could help you better.

Thank you,
Mary

[Bill_French]

The_Redirections_Gro:

I’d like to use Integromat or Zapier to update records in Base B as the records change in Base A.

Hmmmm… This seems completely unnecessary or I’m just a bit dense (cannot rule that out, of course).

Why not share a single base to all users each based on their constrained edit/read-only rights? We do this all the time.

[The_Redirection]

@M_k - I’ve attached screenshots of the basic concept I’m trying to accomplish.

@Bill.French - Perhaps not, but not sure I can accomplish with just read only rights. Base A contains all of my clients’ information and Base B contains client specific information. Instead of sending links to 75+ different records in Base A, I’ve created a separate Base B with just the one client’s information. They shouldn’t have access to all of the information in Base A.

[Nathalie_Collin]

Hi @The_Redirections_Gro

I tend to agree with @Bill.French. What you’re trying to accomplish can be done within Airtable.

You can create views (one for each client) with only the fields that you require them to see and then share that view with them.

For example. Here is a full view of a sample Project Base. Notice all the clients and fields.

Now go and create a new view and customize it with only the fields that you would like your customer to see. Once complete, click on SHARE VIEW BUTTON from the tool bar, as seen in this image.

From there, I typically uncheck the ALLOW VIEWERS TO COPY DATA OUT OF THIS VIEW. What’s really important here is to not select the SHOW ALL FIELDS IN EXPANDED RECORDS.

Here’s the end result. This shows just one client, in this case Bigelow Tea and it only shows the fields that I left visible.

Airtable

Client - Bigelow Tea - Airtable

Explore the "Client - Bigelow Tea" view on Airtable.

NOTE: VERY IMPORTANT: This view changes live and if you happen to be working in that view, and expand things (unhide fields), it will expand it for the client as well. So my recommendation is to create the view and leave it until such time that you want to remove it.

[Bill_French]

The_Redirections_Gro:

a separate Base B with just the one client’s information

Ahhhh, well that’s a key requirement; the need for distributed client-level access. Okay, so here’s what you can do.

Nothing. :winking_face:

Seriously, though - using distinct bases to simulate a distributed information architecture is nutty. I’m not suggesting you are nutty; just the approach. Airtable has forced you to consider a nutty approach.

No solution was ever made better by making copies of data.

Who’s the famous dude that said this? Me. But it’s the truth.

The instant you create an architecture that depends on synchronizing information by value, you have designed a brittle solution. You really want to make data accessible by reference so that there’s no latency in updates and no duplication machinery that can ever fail.

What you need is an abstraction layer between your clients and their read-only data. Separate bases do provide that abstraction, but it comes with a dance with the devil and there are better ways.

One Word - Web

Have you considered using the API to build a simple web app to expose the client data? Perhaps you should look at Table2Site.

[The_Redirection]

@Nathalie_Collins - I agree that is a great approach. However, I want to give this client access to their records at all times. We work in Base A daily and work on other client’s information regularly - of which, they should not see. So unfortunately, I don’t think the specific view is an option long term.

@Bill.French - I know we’ve created a nutty situation. Hence, the need for help :winking_face: One would think that you could freeze records and create a view suggested by @Nathalie_Collins without the risk of a client seeing information of another client. I’ll take a look at the Table2Site.

[Bill_French]

Nathalie_Collins:

You can create views (one for each client)

@Nathalie_Collins, I considered this idea but creating and managing 75 views (1 per client) doesn’t seem that much different than doing the same with separate bases.

And there’s no way to use the API to generate and manage the views and the access controls required. Seems like another set of maintenance nightmares. But it is a good workaround at lower scale.

[Bill_French]

The_Redirections_Gro:

without the risk of a client seeing information of another client.

Yeah, I totally see your challenge. And depending on the nature of your data, you may run into a compliance/security problem. Some industries (and some data types) fall under regulations that prohibit the logical and physical blending of separate client’s information in the same namespace.

Abstraction away from the core database with a wholly separate access control layer is often the only way to meet these compliance requirements.

You need a middle-ware solution - one that provides access control agility, security, and in a way that provides precision filtering from the data source.

[Nathalie_Collin]

The_Redirections_Gro:

I want to give this client access to their records at all times

@The_Redirections_Gro - the link never expires. As long as they have that link, they can forever view their information. I do this with my clients. I set them up with a link that is just for them and at any time, they can view what I’m working on. Additionally, they have the option to sort, filter and group with whatever information is left for them to view. Pretty much all they would ever need is all in one link.

Having said that though, if your information falls within an industry that requires strict data management solutions, then this option is not viable.

Bill.French:

creating and managing 75 views (1 per client) doesn’t seem that much different than doing the same with separate bases

@Bill.French - My concern is that by creating view versus new bases, you eliminate the chaos that is created when the design of the new base is altered. Let’s think into the future when it’s decided that we need to collect additional data. If it’s all in one base, we can alter it and that it – very easy. If it’s spread out across 75 bases, you now have 75 bases to adjust. :woozy_face: