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

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.

@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.

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.

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.

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.

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.

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.

@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.

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.

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.

@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.

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.

@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 - 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:

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 aat 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.

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.

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.

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?

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

@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).

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

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?

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:

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/

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’ …

Hi @The_Redirections_Gro

It took me a few days and some help with Integromat to work out a scenario that will update records from Table A to Table B.

I will include screenshots. Please follow the setup as shown, especially when choosing the ID tag, it should be from module #9. I also attached images of the two bases. I realize that you might want to try something else, but I thought I would post this option too.

If you have any questions, let me know.

Mary K