Noobie question: I need help from airtable experts, Currently I'm not able to followup on my leads properly

Isn’t it possible for the script to run automatically every 15 minutes and it gathers the most current data ?

If the user have to click on things, the crm isn’t doing its job.

I believe it’s possible to do it via automation. The automation could trigger based on the status change to “Negotiation State” that you mentioned earlier, and copy the record to the working table. Once the status changes to any other option, another automation could be triggered that removes the associated record from the working table.

Here i took the screen shot of how it looks like. I’m unable to select when the status option changes to particular value… Please help me.

You’re using the wrong trigger. The one you want is “When record matches conditions.” The settings are the same as those for view filters, so you’ll want to set it to trigger when that {Status} field is “Negotiation State”.

I just realized that the trickiest part of this is going to be syncing back to the original record from the copy. You won’t be able to just use an “Update record” action because that requires you to pick a specific table. The table can’t be chosen via data; i.e. there’s no way to store the record’s original table and use that as part of the update. The update will have to be done via a script action in the automation, and even then, it’s going to be tricky to set up.

You’re using the wrong trigger. The one you want is “When record matches conditions.” The settings are the same as those for view filters, so you’ll want to set it to trigger when that {Status} field is “Negotiation State”.

I just realized that the trickiest part of this is going to be syncing back to the original record from the copy. You won’t be able to just use an “Update record” action because that requires you to pick a specific table. The table can’t be chosen via data; i.e. there’s no way to store the record’s original table and use that as part of the update. The update will have to be done via a script action in the automation, and even then, it’s going to be tricky to set up.

You’re using the wrong trigger. The one you want is “When record matches conditions.” The settings are the same as those for view filters, so you’ll want to set it to trigger when that {Status} field is “Negotiation State”.

I just realized that the trickiest part of this is going to be syncing back to the original record from the copy. You won’t be able to just use an “Update record” action because that requires you to pick a specific table. The table can’t be chosen via data; i.e. there’s no way to store the record’s original table and use that as part of the update. The update will have to be done via a script action in the automation, and even then, it’s going to be tricky to set up.

I think the tricky part would be dealing with changes to the data in the original tables other than setting the {Status} to “Negotiation State”. How will any additional changes to the original record be propagated to the the “working” table? How will the automation know which existing record in the working table record to update? It could be done with a series of linked records or another field to store the “working” record ID. But it would have to be done with a script since automations currently don’t have a “find” action or an “if”.

A deeper problem would be changing the record out of the “Negotiation State”, which could theoretically happen from either table. When the “working” record changes out of the “Negotiation State”, it would need an automation to update the “source” record and delete itself. The source record would also need an automation to delete the working record when its state is changed. But what happens when the working record triggers the automation update the source record and delete itself? Then the source record would have a state change and want to run its automation because the automation can’t tell if the trigger was a human data change or the result of a previous automation. Then that automation script would need to deal with the fact that the working record that it wants to delete might already be deleted. So, while it is all possible, the code involved to protect the data integrity is not worth the trouble.

On another note, currently the only way to delete a record with an automation is with an action script. So, I guess my earlier comment about being able to do it with 20+ automations each way (40 total) would need an additional step of having a filtered view in the working table to hide all the old, no-longer-valid records.

This doesn’t even take into consideration the limits on the number of automation runs per month. The free plan allows only 100 automations per month and doesn’t allow scripting actions. Each record would require at least 2 automations (one to copy it to the working table another to copy it back to the source). So that’s 50 record changes in a month, which would be about 1-2 records to change per day. The plus plan has 5,000 runs per month, which would allow 50 times as many automations, and scripting automations. However, the total number of automation runs would be the same. So that’s about 50-100 records that could change per day, which still might not be enough depending on how many changes there are (including incremental changes to text fields and such).

ETA: There is a limit of 25 automations per base. So, having 40 automations (20 each way) won’t work.

Its shameful that this is going to be tricky because in my view this is a basic requirement for users to manage multiple tables which & air tables should have provided out of box solution for this.

Well under the hood, its a very simple thing,

1. In following records.
2. Find records that have status flag equal to ‘Negotiation’
3. Display them in the view/ Table.

I don’t think the resulting view even have to have same table structure. Just show the result how ever it is.

@Jason Do you have plans to provide this feature out of box anytime soon ?

Heres how out of box feature look like.

Its called favorites in Asana.

You can pick what you want & it shows you the results of it.

I’ve never used Asana, but to me, that looks very similar to creating a filter on a view. From what I see, they’re using a series of filters to create favorites from tasks, which (guessing) are in a single collection of all tasks, not spread across 20 different collections. Airtable’s views are essentially favorites: make them once, and then come back to them any time you want.

@Kamille_Parks I appreciate the clarification, but @Jay_P tagged Jason, not me. Not sure if Jay discovered elsewhere that Jason is an Airtable employee, or if it was simply a Justin/Jason mix-up (I get that a lot). My guess is that it’s the former, and Jay would like to know from someone on the inside if something like this is on the development roadmap.

To that point, Jay, Airtable staff have never revealed their development plans publicly. The only time we get advance knowledge of upcoming features is when they choose to release a beta. Sometimes that’s a public beta, other times it’s private to a select few, but in either case the feature is far enough along that the team has decided to pull back the curtain and let folks take it for a spin if they choose. All other features in development are not revealed until release.

Returning to your earlier comment about how you feel this is “a basic requirement for users,” I respectfully disagree. In your subject line, you admitted that you were a new Airtable user, and you asked in your opening post how to make your setup more efficient. All of my experience is that spreading similar data across multiple tables is inefficient, and I believe that others who have commented in this thread would back that up. There are very rare cases where having identical setups in multiple tables is actually necessary (I ran into one about a week ago, but it’s the first one I’ve seen in the 18 months I’ve been using Airtable). More often than not, a user’s desire for similar data across multiple tables is a holdover from how other software is designed. When we clarify that Airtable is designed differently, and share the benefits of single-table design using views, most people see right away that a single table is far more efficient.

We’ve tried to come up with a way to make this work across your current multiple-table setup, but I think that the latest comment from @kuovonne makes it pretty clear that this is beyond “tricky.” Trying to bend Airtable to operate the way you want is a major technical challenge, with some limitations that literally can’t be overcome.

That takes me back to the single-table solution. If you need to make 50 views in that table, I don’t see how navigating those views would be much different than navigating 50 tables. You’re just scrolling through a vertical list on the side vs tabs at the top (and there are keyboard shortcuts to make that navigation even easier). More importantly, though, putting everything into a single table eliminates all of the technical hurdles we’ve been talking about.

If navigating 50 views still feels like it would be too cumbersome, here’s something to consider. Instead of making 50 views (one for each state), what if you had one view that you could easily switch between states? Most people think of manually modifying a view’s filter settings to change the records that it displays, but another option is to use a script. This view I’m talking about would only show records with certain data in a special field that this script would update. Run the script, pick a state, and the script updates all records to only show those from that state in that view. That keeps your view count low, and you still have the many, many benefits of having everything in a single table.

We’ve given you the best advice we know regarding efficient base design, and encouraged you to follow that design and learn how Airtable operates most efficiently. If you don’t want to follow that advice, then I’m not sure what else I can offer.

I’ve never used Asana, but to me, that looks very similar to creating a filter on a view. From what I see, they’re using a series of filters to create favorites from tasks, which (guessing) are in a single collection of all tasks, not spread across 20 different collections. Airtable’s views are essentially favorites: make them once, and then come back to them any time you want.

@Kamille_Parks I appreciate the clarification, but @Jay_P tagged Jason, not me. Not sure if Jay discovered elsewhere that Jason is an Airtable employee, or if it was simply a Justin/Jason mix-up (I get that a lot). My guess is that it’s the former, and Jay would like to know from someone on the inside if something like this is on the development roadmap.

To that point, Jay, Airtable staff have never revealed their development plans publicly. The only time we get advance knowledge of upcoming features is when they choose to release a beta. Sometimes that’s a public beta, other times it’s private to a select few, but in either case the feature is far enough along that the team has decided to pull back the curtain and let folks take it for a spin if they choose. All other features in development are not revealed until release.

Returning to your earlier comment about how you feel this is “a basic requirement for users,” I respectfully disagree. In your subject line, you admitted that you were a new Airtable user, and you asked in your opening post how to make your setup more efficient. All of my experience is that spreading similar data across multiple tables is inefficient, and I believe that others who have commented in this thread would back that up. There are very rare cases where having identical setups in multiple tables is actually necessary (I ran into one about a week ago, but it’s the first one I’ve seen in the 18 months I’ve been using Airtable). More often than not, a user’s desire for similar data across multiple tables is a holdover from how other software is designed. When we clarify that Airtable is designed differently, and share the benefits of single-table design using views, most people see right away that a single table is far more efficient.

We’ve tried to come up with a way to make this work across your current multiple-table setup, but I think that the latest comment from @kuovonne makes it pretty clear that this is beyond “tricky.” Trying to bend Airtable to operate the way you want is a major technical challenge, with some limitations that literally can’t be overcome.

That takes me back to the single-table solution. If you need to make 50 views in that table, I don’t see how navigating those views would be much different than navigating 50 tables. You’re just scrolling through a vertical list on the side vs tabs at the top (and there are keyboard shortcuts to make that navigation even easier). More importantly, though, putting everything into a single table eliminates all of the technical hurdles we’ve been talking about.

If navigating 50 views still feels like it would be too cumbersome, here’s something to consider. Instead of making 50 views (one for each state), what if you had one view that you could easily switch between states? Most people think of manually modifying a view’s filter settings to change the records that it displays, but another option is to use a script. This view I’m talking about would only show records with certain data in a special field that this script would update. Run the script, pick a state, and the script updates all records to only show those from that state in that view. That keeps your view count low, and you still have the many, many benefits of having everything in a single table.

We’ve given you the best advice we know regarding efficient base design, and encouraged you to follow that design and learn how Airtable operates most efficiently. If you don’t want to follow that advice, then I’m not sure what else I can offer.

I’ve never used Asana, but to me, that looks very similar to creating a filter on a view. From what I see, they’re using a series of filters to create favorites from tasks, which (guessing) are in a single collection of all tasks, not spread across 20 different collections. Airtable’s views are essentially favorites: make them once, and then come back to them any time you want.

@Kamille_Parks I appreciate the clarification, but @Jay_P tagged Jason, not me. Not sure if Jay discovered elsewhere that Jason is an Airtable employee, or if it was simply a Justin/Jason mix-up (I get that a lot). My guess is that it’s the former, and Jay would like to know from someone on the inside if something like this is on the development roadmap.

To that point, Jay, Airtable staff have never revealed their development plans publicly. The only time we get advance knowledge of upcoming features is when they choose to release a beta. Sometimes that’s a public beta, other times it’s private to a select few, but in either case the feature is far enough along that the team has decided to pull back the curtain and let folks take it for a spin if they choose. All other features in development are not revealed until release.

Returning to your earlier comment about how you feel this is “a basic requirement for users,” I respectfully disagree. In your subject line, you admitted that you were a new Airtable user, and you asked in your opening post how to make your setup more efficient. All of my experience is that spreading similar data across multiple tables is inefficient, and I believe that others who have commented in this thread would back that up. There are very rare cases where having identical setups in multiple tables is actually necessary (I ran into one about a week ago, but it’s the first one I’ve seen in the 18 months I’ve been using Airtable). More often than not, a user’s desire for similar data across multiple tables is a holdover from how other software is designed. When we clarify that Airtable is designed differently, and share the benefits of single-table design using views, most people see right away that a single table is far more efficient.

We’ve tried to come up with a way to make this work across your current multiple-table setup, but I think that the latest comment from @kuovonne makes it pretty clear that this is beyond “tricky.” Trying to bend Airtable to operate the way you want is a major technical challenge, with some limitations that literally can’t be overcome.

That takes me back to the single-table solution. If you need to make 50 views in that table, I don’t see how navigating those views would be much different than navigating 50 tables. You’re just scrolling through a vertical list on the side vs tabs at the top (and there are keyboard shortcuts to make that navigation even easier). More importantly, though, putting everything into a single table eliminates all of the technical hurdles we’ve been talking about.

If navigating 50 views still feels like it would be too cumbersome, here’s something to consider. Instead of making 50 views (one for each state), what if you had one view that you could easily switch between states? Most people think of manually modifying a view’s filter settings to change the records that it displays, but another option is to use a script. This view I’m talking about would only show records with certain data in a special field that this script would update. Run the script, pick a state, and the script updates all records to only show those from that state in that view. That keeps your view count low, and you still have the many, many benefits of having everything in a single table.

We’ve given you the best advice we know regarding efficient base design, and encouraged you to follow that design and learn how Airtable operates most efficiently. If you don’t want to follow that advice, then I’m not sure what else I can offer.

:100: - agree with this. Gut feel says this will work in a single table. I’m sure the different priorities by state could be accommodated too. Maybe this isn’t the case, but haven’t seen an example where a single table for a single entity isn’t a better option.

I’ve never used Asana, but to me, that looks very similar to creating a filter on a view. From what I see, they’re using a series of filters to create favorites from tasks, which (guessing) are in a single collection of all tasks, not spread across 20 different collections. Airtable’s views are essentially favorites: make them once, and then come back to them any time you want.

@Kamille_Parks I appreciate the clarification, but @Jay_P tagged Jason, not me. Not sure if Jay discovered elsewhere that Jason is an Airtable employee, or if it was simply a Justin/Jason mix-up (I get that a lot). My guess is that it’s the former, and Jay would like to know from someone on the inside if something like this is on the development roadmap.

To that point, Jay, Airtable staff have never revealed their development plans publicly. The only time we get advance knowledge of upcoming features is when they choose to release a beta. Sometimes that’s a public beta, other times it’s private to a select few, but in either case the feature is far enough along that the team has decided to pull back the curtain and let folks take it for a spin if they choose. All other features in development are not revealed until release.

Returning to your earlier comment about how you feel this is “a basic requirement for users,” I respectfully disagree. In your subject line, you admitted that you were a new Airtable user, and you asked in your opening post how to make your setup more efficient. All of my experience is that spreading similar data across multiple tables is inefficient, and I believe that others who have commented in this thread would back that up. There are very rare cases where having identical setups in multiple tables is actually necessary (I ran into one about a week ago, but it’s the first one I’ve seen in the 18 months I’ve been using Airtable). More often than not, a user’s desire for similar data across multiple tables is a holdover from how other software is designed. When we clarify that Airtable is designed differently, and share the benefits of single-table design using views, most people see right away that a single table is far more efficient.

We’ve tried to come up with a way to make this work across your current multiple-table setup, but I think that the latest comment from @kuovonne makes it pretty clear that this is beyond “tricky.” Trying to bend Airtable to operate the way you want is a major technical challenge, with some limitations that literally can’t be overcome.

That takes me back to the single-table solution. If you need to make 50 views in that table, I don’t see how navigating those views would be much different than navigating 50 tables. You’re just scrolling through a vertical list on the side vs tabs at the top (and there are keyboard shortcuts to make that navigation even easier). More importantly, though, putting everything into a single table eliminates all of the technical hurdles we’ve been talking about.

If navigating 50 views still feels like it would be too cumbersome, here’s something to consider. Instead of making 50 views (one for each state), what if you had one view that you could easily switch between states? Most people think of manually modifying a view’s filter settings to change the records that it displays, but another option is to use a script. This view I’m talking about would only show records with certain data in a special field that this script would update. Run the script, pick a state, and the script updates all records to only show those from that state in that view. That keeps your view count low, and you still have the many, many benefits of having everything in a single table.

We’ve given you the best advice we know regarding efficient base design, and encouraged you to follow that design and learn how Airtable operates most efficiently. If you don’t want to follow that advice, then I’m not sure what else I can offer.

I have been following this thread because it has shown some weaknesses (and oddly, some nice strengths) of Airtable but more important - the weaknesses of specific design and data architecture choices.

We often believe that physical organizations are easier to understand and therefore, should be easier to implement. However, @Justin_Barrett’s deep commentary makes it clear that in this case, a physical differentiation between state leads not only creates a few (if not many) unintended constraints but it is woefully inefficient.

I agree with @Justin_Barrett and @JonathanBowen - this is clearly not a basic requirement and such requirement is rarely pursued across the constellation of database products, let alone Airtable.

However, there are cases where interstate commerce regulations require such organizations; I have no idea if this is one such case. But it would be worth noting to understand from @Jay_P the rigidity of the original source data collection constraints.

Indeed, no one should have to do that. However, if Airtable is the horse you desperately want to ride into the sunset, and these constraints are immovable, you best be carrying cash to a consultant who knows how to overcome these hurdles.

To this point, no one has thought to ask -

How are these original sources collected? Are they manually created via form? Are they imported? Are they generated in a unified data collection and then spun out into separate Airtable tables?

These questions might lead us to realize that Airtable is completely the wrong place to solve the notification challenges.

No one has mentioned scale - how much larger is the 20 original source tables likely to grow towards and how will that impact any given approach that already shows automation at the ceiling.

Yet another point - as I mentioned above, we tend to think of physical (not logical) data collections. With specific deference to the requirements, it may be worth thinking about simply an event architecture that “logs” records that point to leads that need to be visited; you don’t need the entire record to know that something important needs to be attended to. You only need the reference to that record when it meets criteria (i.e., a list of table/record IDs that lead you back to the actual data).

Lastly, there is not much distance between this problem domain and a search engine. What if you indexed all leads data as events occur and then used a search query?

Fascinating conversation.

In previous posts when people ask about the requirement for multiple tables, requirements he has never brought up requirements such as this.

I believe that at one point he said that he imports them on a daily basis. I’m not completely sure.

Other posts imply that there could be 50 tables, one for each state. However, other posts also indicate that he recently upgraded to the Plus plan, with a limit of 5,000 records, but later regretted that decision. Thus, I assume that he will have less than 5,000 records. Again, I could be wrong.

I agree. It has been interesting to participate in this conversation. I am in awe of how so many intelligent people volunteer to come together to help new members of this community.

Yes i manually upload the into the airtable. I love how i can quickly copy paste them into airtable. Monday crm was so rigid.

Q.how much larger is the 20 original source tables likely to grow towards and how will that impact any given approach that already shows automation at the ceiling

It wont grow much but I’ll be definately be adding more tables for other categories.
So I’ll be creating another base I guess for other kind of data and there will be few more kinds coming soon.
Good thing is most of my data structures are exactly the same.

“a basic requirement for users,”

This is 2020 and almost every other competitor tool provides easy way to get all the records out of box. This is a major struggle as I can’t retrieve the important records at one place.
If your crm doesnt help you priotize your tasks/ its not a success.

Strengths = i like how easy it is to copy paste the data from excel.
Its clean.
Easy to create calender tasks.

It’s efficient for us because of prioritization. Data from some states are far more important than others. & It will not be cleaner.

I believe it’s possible to do it via automation. The automation could trigger based on the status change to “Negotiation State” that you mentioned earlier, and copy the record to the working table. Once the status changes to any other option, another automation could be triggered that removes the associated record from the working table.

Thank you for validating @Justin_Barrett’s assertion. :winking_face: The idea of establishing importance or priorities is rendered entirely impossible in a fractured data model.

This is patently false.

My recommendation is to come back with reasoned and rational responses or head back over to Monday or Asana.

I see tremendous upside in Airtable. Lets not be negative and talk how we can make this awesome product even better. Airtable have fleet on engineers, im sure they can figure out solution to common user problems.

Is it possible to use an automation (without a script) to remove a record? I can only seem to modify records using the Update record action, not delete them. Am I missing something?

This currently is not possible. Currently, the only way for an automation to delete a record is with a script.

I see tremendous upside in Airtable. Lets not be negative and talk how we can make this awesome product even better. Airtable have fleet on engineers, im sure they can figure out solution to common user problems.

Would love to engage but without answers to these questions, I have some other users I need to assist.

Top Need. Easy way to track the team’s progress. It could be a view or synched table but it should be able to bring data from multiple tables so a manager can easily know where his team is.
Current Airtable Sync option doesn’t allow the user to make changes on the record in the (summary view).
Atleast it should provide a link to jump to the original table so work can be done efficiently. Also in the past I had created my own crm so I know all these things i m asking is very much possible , not at all hard to achieve. I just dont have time on my hand to code another crm.