Hey ​@Kim_Trager1,

Re: 5 columns/fields shown in the selector, those are the first five fields that you have on the first listed grid view for such table. -see image below, why I lock edit permissions on those views and name them accordingly.

 

Re: Searchable field. I should play around with it. I would also say that it should be primary field. But I see that it is showing same fields shown on the child table itself? Did you try showing the primary field?

I’ll test around with it later today!

Mike, Consultant @ Automatic Nation

Hi ​@Mike_AutomaticN So I also thought I would be one of the views that would control the 5 fields. I have 3 views and none of them have the status column in the top 10 not any of the 4 other fields up front...

​@Mike_AutomaticN So I tried to debug this, and it seems to do some weird behaviour.

I have a list with a link to a button in my interface. Like this:

It seems that the order of the fields in the drop-down selector is actually the order of the fields in the list, and it has nothing to do with the primary view where the button is pointing. When I need to change the order of the fields showing the drop-down, I’ll need to rearrange the columns in the list, delete the button again and then add it back, and it’s updated.

The weird bit: I have two calculated fields. Just an IF(something is present, show the value, if not show “NA”). Every time I introduce one of these two columns to my list, the primary field in the drop-down selector (the searchable column) changes to NA.

Assume this is a bug?

Did some testing on my end to validate what you found about the order of the fields in the selector: they match the first five visible fields in the visualization when you add the button, and that reconfiguring that order requires deleting the button, making the desired changes, and then re-adding the button.

Just some fiddly things and questions that come to mind that may help untangle how/when/why this is happening:

• First: I’d echo what Mike said and see what happens if you unhide the primary field and then delete and re-add the button, to see if that makes Airtable list the primary field as the searchable field. 
• Does setting a filter in the button settings to exclude the “NA” values (or exclude records where the field that provides the value is empty, thereby hiding the records that are generating “NA” in that field) make a difference here? (see below)

  

  • If doing the above gets in the way of actually completing the workflow this is supposed to be helping you do (i.e. hides records you would want to be linking here), it’s definitely not a solution to your problem, but if it does make the primary field show up as the searchable field again, that at least gives us some kind of insight. (I think. I hope!)
• You said introducing either of the calculated fields triggers this issue—do they both influence the INCO TERMS field somehow (presuming that’s the field/value that’s hijacking the primary/searchable field here)? 
• What happens if either of the calculated fields are beyond the first five fields listed in your visualization? i.e. if you make them fields six and seven, and therefore (theoretically) exclude them from the record selection search?
• Is your primary field a formula field and, if yes, is the value of the INCO TERMS field used in the calculation in any way? Might be that too many dynamic calculations is sending Airtable into a tizzy...

If my guess that the primary field is a formula field is incorrect, please set me straight, but if I’m right, my instinct is that the issue lies somewhere in there. Whether or not this is a bug or a known (to Airtable devs) limitation, I can’t say, but there still might be something that can be tweaked to snap it out of this behavior…?

Hi ​@stagandforge 

Thanks for this list of debug questions. I’ll take them from the top down:

• First: I’d echo what Mike said and see what happens if you unhide the primary field and then delete and re-add the button, to see if that makes Airtable list the primary field as the searchable field. 

I tried all this initially, but it didn’t change things. It’s literally the first time one of the two fields is added to the list.

• Does setting a filter in the button settings to exclude the “NA” values (or exclude records where the field that provides the value is empty, thereby hiding the records that are generating “NA” in that field) make a difference here? (see below)

This wouldn’t work for me as I have some dynamic filtering set. However, I just took these off, but it’s still the same.

• You said introducing either of the calculated fields triggers this issue—do they both influence the INCO TERMS field somehow (presuming that’s the field/value that’s hijacking the primary/searchable field here)?

So I have the commercial invoice, which is a parent to a goods note, which is a grandparent to a sales line. Commercial Invoice → Goods Note → Sales line. Both sales lines and goods notes are created from API input and linked together by automation. Then it’s just the user role to put it all together on a commercial invoice and send those out to customers. The inco terms are sometimes included in the Goods note API upload, sometimes not. So there is an ability with a dropdown to overwrite all the INCO terms for the full invoice. So there is a simple lookup in the Goods note table that looks up any overwritten INCO term set on the invoice level. Then the calculated INCO term column is just an IF(overwritten INCO, Overwritten INCO, INCO from API upload). The other field in question works similarly. So it’s not even near the primary field, which is a single text column as it’s being populated by the API.

• What happens if either of the calculated fields are beyond the first five fields listed in your visualization? i.e. if you make them fields six and seven, and therefore (theoretically) exclude them from the record selection search?

​​​​​​​Same. The order seems not to matter. I just put it front and centre for my screenshot. The only thing is to say it seems the issue first shows after I publish the interface. Similarly, when I take the columns out of my list, I need to publish again to make it work again.

• What happens if either of the calculated fields are beyond the first five fields listed in your visualization? i.e. if you make them fields six and seven, and therefore (theoretically) exclude them from the record selection search?

​​​​​​​Single text column as it’s populated by an API, which is what makes it even more curious, as it’s almost as disconnected as you can get from the INCO term column, except for sharing the same table.