Viewing view name in row

I generally avoid asking user why they want something because they almost always have good reasons for asking. However, this ask seems a bit odd (or I just don’t understand the reasoning).

The selected view is already visible to users in the upper right of the UI. Why would every record need to replicate this information? Furthermore, wouldn’t the value of this field need to change every time someone selected a different view?

Help us understand the benefit of consuming script automation time and actions to achieve this.

Thanks in advance Bill. Basically each view has a unique filter and based on this filter i need a number output assigned to a user, at this moment the number is the view’s name, i tried doing this procedure with automations but the limit is 25 automations when i have more than a 100. The result I need is being able to have a number output based on filters in my user data row because then I pull that data from another app.

This is a good example illustrating why it’s important to share a brief narrative of the objectives of the solution.

Some observations… (correct any of them where my assumptions are wrong)

1. There are about 100 different users who need access to slices of your data.
2. An external app is used by each of these users.
3. The external app knows who each user is (i.e., via some sort of ID number).
4. The external app needs to retrieve a portion of the records from the Airtable database based on that user ID.
5. Your interest in building 100 views is to support the idea that the app must limit exposure of applicable records to the different users.
6. The number of users is likely to grow or at least change over time requiring the creation/maintenance of available views.

Assessment…

In my “view” (pun intended) you need exactly zero views to achieve your objectives. In fact, any attempt to map 100+ users to specific views (in this case) would likely create more problems than it would solve. Since the Airtable’s API lacks any ability to instantiate views dynamically and managing manually-maintained views is woefully unsustainable, we must find another way.

I believe the answer is in the external app. If it has the ability to ingest a view (presumably using the Airtable API or some other glue-factory service), it also has the ability to request an extract of the data that is not only sorted, but also filtered using such features in the Airtable API.

filterByFormula and sort can be used to create views dynamically, making it possible to tag your data records with a specific user’s name, ID, or any other value that allows the external app to access only those records.

In this approach, you never create views for specific users; rather - you simply allow the external app to identify which user’s records it needs.

Make sense?

Hi Bill, let me explain better, my users sign up and their data is pushed to airtable. After this step I perform some calculations in airtable with formulas and based on the results I must automatically assign the users to a certain diet (we provide custom meal plans based on food preferences), these “diets” are views at the moment and when a record enters a view i automatically send that user to mailchimp where he will be assigned onto a user journey and receive his diet plan weekly, but to do this assignation I must know which diet he has been assigned to (which view he entered) so I would need some sort of formula that lets me send over to mailchimp the number of the view (diet) the user must follow.

Yep - and that number is the view ID - it’s automatically created and assigned by Airtable for every view created. For example, this new API endpoint allows you to get all of the view names and IDs. Then, it’s a matter of using that APU meta-data to construct and deliver the links to the individual users.

I continue to believe that virtualizing a dynamic approach is ultimately going to be more sustainable.