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!

[Bill_French]

Nathalie_Collins:

creating view versus new bases

Nathalie,

Indeed. A poor choice of words by me - separate bases for each client is a far worse approach than client-specific views and especially so without an admin-level API for automation.

Base abstraction is wholly untenable (in the nutty category). Views are untenable [at scale] - but far more useful in the scale of dozens perhaps - kind of falls into the fruit and nuts category - it’s trail mix! :winking_face: I typically enjoy trail mix while hiking to a steak restaurant. Sorry, I’ve clearly gone overboard with metaphors.

In either approach, I puke in my mouth a little at the thought of many ways these approaches could go bad at scale.

[Nathalie_Collin]

I completely agree. I privately wish that Airtable would enhance permissions so that we could granulate things to a point that we didn’t have to ‘think’ through hoops to complete things.

[The_Redirection]

Our data is not within an industry of strict data management. I just don’t want one client to see the other’s information.

Maybe I’m not understanding the way you set up the view link. I did your initial suggestion above, but once I remove that client’s filter, the view link shows all data in the base, not just the client’s data when I created the link.

[Nathalie_Collin]

The_Redirections_Gro:

but once I remove that client’s filter, the view link shows all data in the base

Aww, I see what you’re doing. You cannot alter that view once you’ve created it for that client. I can hop on a call today if you’d like and I can showcase it, but basically what you want to do is;

1. duplicate your existing view or create a new view
2. update that view for client 1
3. rename it as client 1 and then share it.
4. rinse and repeat for each client

so in the end, you would have YOUR main view, and the others would be all the CLIENT views that you would just leave alone and never alter. Make sense?

[The_Redirection]

Got it! Yes! This is exactly what I need. I was not aware that you can create new views and rename them. Thanks for the extra step in instructions with this.

Have a great day :slightly_smiling_face:

[Bill_French]

Bill.French:

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_Collins - I described the exact requirements needed and it seems that your view approach is darn near spot-on. The use of the share at the view level is quite tempting and really does address objective in a pretty good way, so I must agree - setting aside the scale (75 views) this is a really good approach. Thanks for teaching me.

To be clear - a shared view link is publicly accessible, right? If anyone got their hands on it or if it ended up in a search engine, the data would be not only openly available but findable (I think).

[UPDATE] I see no evidence that Google has ever indexed a shared [public] URL, so that’s good. It’s likely they [Airtable] are guarding these obscure URLs from indexing crawlers ever getting hold of them.

[Nathalie_Collin]

Yes, I do agree, it’s not secure. I’ve never had a client to look into this for, but is anything we do in Airtable truly secure? What options do we have?

[Bill_French]

Nathalie_Collins:

is anything we do in Airtable truly secure?

I think so. For the most part, users are interacting with data over HTTPS with credentials, so it’s pretty good. And data at rest is ISO and SOC compliant. I have no worries about their security architecture - it’s all up to par.

When it comes to creature comforts (like easy link sharing) is where users get into some trouble so they need to be aware of what they’re doing.

The only ding I could level at Airtable is the lack of signed URLs for attachments. The URLs for attachments are publicly accessible all the time - no share step is required. As such, any exposure of these URLs in the clear (such as an email message) would create a possible breach. Ideally, a signed URL could be used that makes the address expire after some selectable time period.

I lose sleep over a lot of Airtable stuff, but security is not one of them. :winking_face:

[Kamille_Parks]

I know I’m late to the party, but @The_Redirections_Gro you may want to consider joining the Airportal beta, which is 3rd party supplimentary webapp which will allow you to deploy client portals, allowing your clients to only see relevant info.

https://airportal.app/

[Bill_French]

Kamille_Parks:

joining the Airportal beta

I don’t think I’ve signed an NDA with the Airportal folks but I’m going to assume one exists so I won’t elaborate with any details. But I gotta’s say - Airportal is the real deal - thoughtfully designed, possesses the user chumminess and the true spirit of Airtable, and the essential functionality is simple and elegant.

Just sayin’ …