Currently, Ref fields only allow searching by the table’s Label column. In many cases, developers have to create concatenated labels (eg, Customer ID - Customer Name, Customer Name - Phone No, Product ID - Product Name, etc) just to give users enough context to select the correct record.
This leads to unnecessary virtual columns, additional expressions, and extra maintenance overhead.
A better approach would be an advanced search/filter experience for Ref fields, allowing users to search across multiple columns and optionally filter records before making a selection.
For example, when selecting a customer, users could search by Customer ID, Customer Name, Email ID, Phone No, or City instead of being limited to a single Label value.
Most platforms with relational data models already provide this capability, and it would significantly improve usability for apps with large datasets while reducing the need for CONCATENATE() workarounds and supporting virtual columns.
This seems like a relatively small enhancement that could deliver a big boost in both user efficiency and app performance. Thoughts?
Hi @interact-yugal
What do you mean like this?
click search, then click the triangle button, then a selection filter will appear according to the data type column that you checked for the search.
To clarify, my request is specifically about the record selection experience of Ref fields while editing data—whether that’s in a Form view, Table view, Detail quick-edit, or any other input interface where a Ref value needs to be assigned.
Currently, users can only search against the Label column, which often forces developers to create concatenated labels purely for lookup purposes.
What I’m proposing is either:
An advanced lookup/filter dialog similar to what many relational systems provide, where users can search and filter across multiple columns before selecting a record.
Or a hover/pop-up table view that displays key columns and allows users to quickly find and assign the desired Ref value.
The goal is to make Ref selection easier and more efficient, especially when working with large datasets, while reducing the need for CONCATENATE()-based labels and supporting virtual columns.
Hi @interact-yugal
Oh, sorry if that’s not what you meant, maybe you meant if you select the customer name label for the ref, but what appears in the table is the key value (ID). Yes, that also annoys me, because I can’t freely choose the column for the ref. AppSheet should provide the appropriate results in the ref display. (the selected label) even though it’s not the key. I agree with your feature request. Because it looks easy but finding a solution is quite long. My solution to deal with this is to create a shadow column with a formula that can produce the value in the ref column.
This is a useful feature request. 
Till such time, one possible way is to add all those options in another search column and then zero down on the reference column from the reduced options in the ref column. This can typically work well with smaller reference tables.
The screenshot below shows that ALL the search options ( name, email, phone, city ) are included in the search column.
In the above image, the Customer_Search is an all inclusive search column where customer names, emails, phones and cities are all included. The [Customer_Name] below it is the reference column.
The user can search by any of those options and the ref column [Customer Name] will show only applicable options to select from.
In the screenshot below the user searches by phone number
In the screenshot below, the user searches by the email ID
The [Customer_Search] column has the following suggested_Values expression.
Customers[Name]+Customers[Email]+Customers[City]+Customers[Phone]
The [Customer_Name] has the following valid_if expression.
SELECT(Customers[Name],
OR([Phone]=[_THISROW].[Customer_Search],
[Email]=[_THISROW].[Customer_Search],
[City]=[_THISROW].[Customer_Search],
[Name]=[_THISROW].[Customer_Search])
)
You can achieve this by adding the child records from the parent table itself (Customers table in this case) with an inline action ( In the screenshot below , the Add Order inline action) . So in the parent table view, the user can easily search the desired record using AppSheet’s native search option using any column value. In the screenshot below, only email and phone are concatenated as a text column because AppSheet shows those with action icons in table or summery views.
Then use an inline action of LINKTOFORM() to prepopulate the child table’s reference column with the parent table key. Then the user can fill in the remaining child table form ( in the example Orders form)
We see the process in action in a GIF.
Please ignore the Search_Cucsotmer column in the Orders form that was added to demo concept in the earlier post. In this example, user searched customer by phone number.
Hi @Suvrutt_Gurjar ,
Appreciate your response and suggestion.
I agree that inline actions can help in scenarios where Ref relationships are limited and manageable.
However, in workflow-heavy applications with 20+ interconnected tables and multiple cross references, this approach quickly becomes difficult to scale.
Manually creating separate inline views/actions for every form, child table, and Ref relationship introduces a significant maintenance burden. Any UI or logic change then has to be replicated across many places.
Further, this approach effectively supports only one Ref mapping flow per table/form setup. In real-world applications, forms often contain multiple Ref columns pointing to different datasets. Creating and maintaining separate inline lookup experiences for every Ref field becomes impractical very quickly.
Hi @interact-yugal ,
Thank you very much for presenting more scenarios.
As mentioned at the beginning, your feature request has a use case for sure.
The options suggested are till the feature request is implemented. Going by the latest announcement by AppSheet team on emphasis on stability, new feature requests could take still longer. Hence suggestion on alternative approaches. Some feature requests , endorsed by many are in suggestion stage for multiple years. Please refer below request as an example, highly seconded by multiple community members.
In multiple reference scenarios , one can use a search column approach discussed earlier.
