Quick Base Announcements

Sneak Peek: Type-Ahead Search Picker

By Sam Jones posted 09-19-2018 20:17


While we at Quick Base love to work on great new features, like Kanban reports or Automations, we also take time to focus on the fundamentals. And what could be more fundamental to Quick Base than quickly and accurately entering data? 

So many of our customers tell us they come to Quick Base apps because theyÕve outgrown spreadsheets and need to move to a relational database to handle the complexity of the work they need to track. Recently, weÕve been taking a hard look at how we can improve this fundamental activity of Quick Base apps: relating data.

What did we find? After talking to customers with big data sets and small, we realized our record picker needed to be better at finding records quickly and making sure users knew exactly what record they were picking! 

If youÕre not familiar with our record picker, hereÕs a crash course. (You can find out more about configuring it in Quick Base University.)

When youÕre working with a relatively small data set, we show a simple HTML drop down. It works well if youÕve got some easily discernible records and you know what youÕre looking for, but if youÕve got a larger set of data, it can be much harder to find what youÕre looking for.

Now, one of the things we all love about Quick Base is how deeply customizable it is. So what if I want to only pick from records which meet a certain criteria? Or if I want to make sure the most likely to be picked options are at the top? Quick Base has a solve for that! In the form properties, you can choose a report on which to base the record picker, which allows you filter and sort the field. 

ItÕs great that you can apply sorts and filters, but unless you really trim down the columns, it can be really hard to read for end users. Beyond that, they may not understand what data is displayed in the list and given that each record displays all its data on one line, it can be hard to match up values to compare them.

In addition, our users told us they expected to search through these records to find what they were looking for, but our simple record dropdown doesnÕt support that. For search, we need to go into the record picker pop-up. 

In field properties, you can configure this relationship to always use our record picker pop-up but getting to it requires more clicks and takes the user out of the context of the record theyÕre editing.

What we found in talking to customers was that their teams needed a faster way to search their data.

After seeing all this, we got to work. Presenting the new Quick Base Type-Ahead Search Picker:

If your app builder has chosen to display only one field to pick records on, weÕre now going to present a fast, searchable picker, very much like the new field picker we rolled out back in spring or the user picker we've have. 

If your app builder has chosen a report or the standard record picker to select from, youÕll see a multicolumn picker, able to display up to nine fields of relevant data, with each column labeled so users clearly can see what theyÕre picking from.

We load the first 50 results automatically, so users can browse. As you search, the list updates in real time, pulling in more records and highlighting the matching terms, very much like our user field type. 

This new picker will be rolling out to all users in the coming months. If youÕd like a sneak preview, we have it available in early access starting the week of September 24th. Just have your realm administrator open a support ticket and request it at https://login.quickbase.com/qb/support/listcases

Thanks for reading and be on the look out for more posts and previews about our new type-ahead search picker!

Sam Jones
Quick Base Product Manager


02-25-2019 16:06

Hi George, I'm sorry to hear your customers are having trouble. We see the new search picker as the next step in making Quick Base more modern and simpler to use. So while we would not be able to disable the new style, our Customer Care team will be happy to help out with any specific issues you're running into. You can open a support case by clicking the "?" icon, clicking "Manage Support Cases", then click "+ New Support Case"

Thank you, 

02-25-2019 15:55

Any way to disable this feature? My customer like it the old way :-(

02-16-2019 15:40

This is great but I have noticed one limitation on mobile. There is no link to add a new record in the parent table. Is this coming?

11-12-2018 23:01

Yes, I did a test just now and I agree it working the way we all wanted it to.  That is great.

I'm going to circle though my main clients now and suggest they go on EA for Record Picker!

11-12-2018 22:24

This is released. You should now see the change.

11-09-2018 15:46

Thx. Hopefully because it?s EA it does not have to wait for the next Monthly release.

11-09-2018 15:37

As an FYI, this will not make Sunday's release. I will keep everyone updated. It shouldn't be too long.

11-08-2018 16:23

Thank you for all the ongoing improvements!

11-08-2018 15:59

Also a big thanks from me for helping us keep things working the way we've designed them over the years!  This is one of the things I love about QuickBase, it's willingness to listen to users.  Looking forward to using this feature on more of my apps.

11-08-2018 15:53

Thank you for listening and good luck gettin' it squeezed into this release.  I have some clients I would love to move to EA for this great new type head feature, once that is "fixed" in EA.

11-08-2018 15:51

With this Sunday's release, we should be removing the inserted Record ID#. I say should because we are close to the release and are trying to make it in.

This should respect any record picker or report configurations a builder has setup.

11-06-2018 20:43

Just reporting back that I had my demo with Harrison who has taken over this project from Sam Jones, and he sees my point and will circle back to the Software Engineers.  It's still in EA, so not yet GA this next November release, so still a work in process to get it right.

11-05-2018 19:05

Harrison and I have a date for tomorrow for me to demo a nice clean example where the EA exposes the Record ID in viewing a record (in edit mode).

I will also add my thoughts to yours during the demo that if we, as developers,  created a record picker selection (in Advanced Properties) for a specific report on the form to use for the Drop down list which does NOT include the Record ID#, please please please do not assume that we love to expose our users to the Record ID#.  It's just clutter for the User's brain to filter out and also right now it is the first field on the drop down report, so the user needs to mentally scan past that [Record ID#] to see the real fields for "picking a record".

Of course, this can be avoided by by using a proper reference proxy, but there so many old app out the that will be affected and then like you say, if we want to expose the [Record ID#] to users (e.g. it is actually used as the Order#), we are free to do so in the drop down report or the Record Picker settings.

11-05-2018 18:54

Harrison, I think the point that many of us have tried to make in this thread is that as developers we have gone to a lot of effort over the years to hide the record ID in these drop-downs, because 99% of the time they are useless to the end user and just equate to more "noise".  Rolling out a new feature that retroactively defeats those efforts and sticks the record ID back into the UI (when we have purposefully removed it) is not helping us. Who would want this?  In fact, I would say it's more reasonable to flip your question above around backwards...  "Can you share a use case where you WOULD want the end user to see the record ID?"  With my applications and my users, my answer to that would be virtually never.

11-05-2018 16:55

Hi - Right, what I'm saying is that in _view_, we display the record ID#, if you have no proxy.

We do have a behavior change coming in this release where we will display the record ID# _and_ the first column if the drop down is _not selected_ (you are just "viewing" in "edit").

Based on the responses I'm seeing here, it seems like some there are a few different things being discussed. Both what is displayed in the drop down in edit (the fact we added the Record ID#, which is already visible on view) and what is shown when a value is selected, but the drop down isn't in focus.

Do you want to shoot me an email directly and we can pow wow on this?

11-05-2018 16:40

Harrison, I beg to differ!  Today (not on EA), the user experience for [Related Parent] when there is no Proxy field set, is that in ADD and EDIT mode,  is that the user sees the fields from the custom report on the form.

I'm happy to share an app which will duplicate this scenario with anyone in support.

For example

The custom report on the form is a single column drop down list of Defects from a related table.  The current behavior is the user sees a nice clean single column list of defects and in edit mode while looking at the record, but not actually editing that field, sees words of the various defects.

In EA, that will display in edit mode like like "237" as the Defect.  237 is the Record ID# of the defect and is not meaningful to the user, when they expect to see the words, like "Low Tuft Lines".

I know that I can fix this by changing the app to use a reference proxy, but my concern is that this change will break functionality for thousands of apps.  You don't want these support calls and I don't want to proactively search every app I have ever written looking for where I should have used a reference proxy for apps I built in the last 16 years.  In the early 2000's like 2002 'ish I did not understand what a reference proxy was.  Based on my consulting work where I coach and train, many new users do not understand reference proxies.

Hence I feel that if the developer who specified a report on the form to use for a drop down should continue to have their wishes respected and use that report for the drop down.  If I wanted to expose the Record ID to the user I would have included that on my report used for the drop down.  But its pretty rare to want to expose Record IDs to users, unless it happens to be used as a like an Order# off a number wheel.

11-05-2018 16:23

Hi all. We have spent considerable time on user studies, experience design and investigating expectations of builders. This is not a bug, but was rather an intentional decision based off of extensive research. These drop downs can deliver considerable amounts of data that we want to help people consume easily and reduce confusing.

Today, if you do not have a proxy field, we display the record ID# when viewing a form. All we simply did with this new feature was carry it over into edit mode so there was continuity.

Can you help share a use case where you wouldn't want an end user to see this record ID, since it is something they already see on view?

11-05-2018 12:37

I?m also concerned that where the relationship does not have a Reference Proxy set, that in edit mode it exposes the [Record ID#] to users which is s change in existing behavior (and not good).

There are many thousands of apps out there doing what might be called Manuel reference proxies. By that I mean to show the field related parents in edit mode but in view mode to show the correct look up field.

I fully realize that this can be remedied by sending a proper reference proxy but I personally have written written dozens of apps which back 10 years ago probably had this flaw in their set up but still work perfectly today.

I am still hoping and expecting that bug will be fixed before the GA release on record picker which by the way is an otherwise wonderful enhancement.

I have clients I would like to push over to early access on record picker as it would really help their experience but one client has 100 apps and I really don?t wanna go looking for all the problems proactively.

11-05-2018 03:38

I have the same problem:
And in the new EA drop down, I am seeing record ID # as the first field listed (even though record ID # is specifically excluded from my customized record picker definition).  

Will we be notified when this addressed? Or will it be dealt with in the General Release?

10-10-2018 20:50

It works great so far, I have begun eliminating the "search" boxes one by one, I'm not sure what all else is involved with completely removing autocomplete, other than the boxes and the code page it installed. - cost was a big issue for me, only the select few in the company could use it because of this, it is great now that everyone has this basic capability.

10-10-2018 19:57

I believe so - i tried Softtech's autocomplete and had the same challenge.  Joe's awesome and was ahead of his time with this years ago but the cost was prohibitive.  

10-10-2018 12:19

Is this the final solution on this to replace the record ID with the reference proxy?  Delete and add back the reference?

I submitted and cancelled a support inquiry on this with a work around of adding lookup fields just below the type ahead search so once selected the lookup fields display what the user was accustomed to seeing after selecting a record from the pop up record picker.   This works but the reference proxy working as described would be best. 

10-09-2018 12:31

We have a report with a list of Auditors as a dropdown field. There are about 150 or so auditors but the record picker only displays 50. How can I display all the records beyond the 50 is the user does not know their names and wants to browse the entire list ? Previously you could just scroll down and pick from the dropdown. The ability to switch between search picker and standard multiple choice dropdown would be great.

10-04-2018 19:46

Well thank you very much for your help! Much appreciated. I can't use the type-ahead functionality yet, so this is very helpful. 

10-04-2018 19:38

Ahh ok, yes Grid Edit type reports don't have the same option to set the Grid Edit behavior, they default to what they are set on during creation. Unfortunately, if you set the form at the user level to be used for Grid Edit it will effect the Grid Edit behavior on every report on that table which could mess up other reports and their behavior. In that instance of a Grid Edit type report, instead of a report turned to Grid Edit, it ignores some of those settings we could manipulate. 

10-04-2018 19:32

Just kidding! It works for standard reports, which you then click grid edit on, it just doesn't want to work for grid edit reports for some reason. 

10-04-2018 19:28

No luck... It's still showing me every single possible parent record without filtering based on the report being used for the form it's based on. Could it be because I'm in the admin role?

10-04-2018 19:20

Oh wow, okay! I'll go give that a try. 

10-04-2018 19:15

Thank you for the feedback and insight into your use case Rick. Details like that are very helpful while we are in EA.

10-04-2018 19:14

It is possible to set a report or Grid Edit report to also make use of a report that helps to filter the related choices. It is a little counter-intuitive but you actually are able to do this under the Forms header in that tables settings. You would first want to have a form that has the same fields that the Grid Edit report you are using has and specifically the related field has been set to draw from that specific filtered report you want to use. Once you have a form that has the right fields and reports set up you would then go into the table settings on the child table and click the Form header. 

From there you can click on the option to 'Override role settings by report' to open up a list of all of your reports and then for specific reports instead of using the Standard Behavior or the role settings in the Grid Edit column you can instead set that report to a specific form under the Grid Edit column. This allows you to apply some of those Form specific behaviors (like a field being set to draw from a filtered report) to the Grid Edit experience. I hope that information is helpful Elena. 

10-04-2018 19:13

Gotcha. I think this is consistent with how differently grid edit mode behaves in general compared to a form. It clearly has a very different framework behind it, precluding many desirable form-related features.  Maybe one day we'll see more form-like behaviors woven into grid edit mode, like this new picker! (fingers crossed)

10-04-2018 19:10

It is more useful to have the pop-up picker - as it is expandable to full screen to view more images at one time.  Then use the Search bar to search for image attributes to filter the list with the thumbnail images down to make the selection from

10-04-2018 19:06

In the current stage of the EA there is not an option to revert some fields back to using the pop up record picker either via Form or Field settings. It is helpful to get feedback on this use case though for the pop up record picker and images. In your instance which would be more desirable, the pop up picker being an option or rich text fields/images being included in the Type-Ahead Search Picker?

10-04-2018 19:04

Yes, but not necessarily embedded. The specific report I'm working with is standalone. 

10-04-2018 19:02

No, I mean the dropdown that appears in a grid-edit report when you select a related record. 

10-04-2018 19:01

I think she means while editing an embedded report via grid edit mode.

10-04-2018 18:59

I'm not sure what you mean for a record picker for a report.  Do you mean the Dynamic filters on the left side of a report?

10-04-2018 18:59

As far as I can tell, this feature does not apply to grid edit mode (as is the case with many form-related UI features)...but it sure would be nice if it did!  We also use grid edit very frequently for data entry and being able to link records with this new search picker would be an awesome improvement!

10-04-2018 18:54

Also - on a related note, does anyone know if there is a way to filter the record picker drop down for reports? I know how to do it with forms (by creating a filtered report and setting the field to select records based on that report) but I haven't found a way to do the same with reports. Help?

10-04-2018 18:52

Does anyone know if this will work in reports too? Or just forms? I use a grid edit report for data entry on a table and I'd LOVE to not have to scroll through hundreds of options to select a parent record.

10-04-2018 15:28

I am using the old record picker popup to select art images as we had a thumbnail RichText field that would show on the popup. It looks like now that RichText fields are not available now as part of the Record Picker choices.  We actually use the PopUp Record Picker as they were able to to displayed on there.  Is the old PopUp still available? or is there a way to add RichText fields to the picker?  We use this functionality in many of apps today related to illustrating images to select from.

10-03-2018 21:00

I'm not sure what the third party autocomplete is, but in my use in Early Access for my own developers Realm, it's excellent.  If you type parts of two words for example, it will also get hits.  That can be very useful for filtering long lists. 

10-03-2018 20:57

Will this be a good replacement for the third party "autocomplete" for quickbase?
I hated to pay for something extra, that should have been native to begin with.

10-03-2018 20:21


09-28-2018 19:26

Thanks for confirming this shouldn't be happening.  I have seemingly fixed the issue by deleting and recreating the reference proxy, and re-adding to the forms in question.  I can now successfully hide the related record ID # in both the standard record picker and using a custom report for the drop-down.  This rocks, good work! Thanks.

09-28-2018 18:53

@josh and @mark,
Open support tickets. Our team can help figure out what's going on.

Sam Jones
Quick Base Product Manager

09-28-2018 16:36

Ditto for me.  I don't want a record ID to be forced on users. That is the reason that we have Proxies. 

09-28-2018 16:31

I am seeing the same behavior described above, except that I am using no conditional values on my form, and I am using a "proper reference proxy".  

In view mode, I see the reference proxy field as usual, but now with the EA feature, in edit mode the field changes to the related record ID #.  And in the new EA drop down, I am seeing record ID # as the first field listed (even though record ID # is specifically excluded from my customized record picker definition).  I have tried changing from 'standard record picker' to a customized report for the picker drop down (which also does not include record ID #), yet still the record ID # field is being inserted into the drop down as the first field.  

Is there currently not a way to hide the related record ID # in the new searchable EA drop down feature?  As mentioned above, the record ID # is useless in this scenario and will only serve to confuse users.  I have put effort into hiding this field, now it seems I don't have that option?

09-27-2018 17:25

If they're seeing the record ID, it's likely set as the field to be displayed on the form, so in the old setup, they would see Record ID on the View mode, and the pick list on the edit mode. We're trying to get View and Edit more aligned if they're both based on the same form.

09-27-2018 17:21

Well, I really do not want the users seeing [Record ID#] at all when they didn't used to.  But at least the exception you suggest will allow the app to be usable.  And of course if there are complaints from users, the fix is to use a proper reference proxy.

But what I do not get in your suggestion is why, if the report being used on the form is what the user should be seeing, then why show the Record ID at all?  If I wanted to show the Record ID, I would have listed that column on the record picker report. 

09-27-2018 17:16

@Mark/ Quick Base Coach,
Yeah, I'm concerned about breakage too. We're thinking about making a special exception: If the single field which would be displayed is the Record ID#, then appending the second field from the picker, which would likely be the identifying value.

Sam Jones
Quick Base Product Manager

09-27-2018 17:11

My point here is that I happened to be testing on an older app written around 2005 before I understood "Reference Proxies" in Relationships.  So I did manual Proxies. I used [related parent] in add/edit mode on the form and [Parent name] in view mode.

On the Original app not in EA it works fine.  The form is set  to use a report where the drop down choices for the record picker is just the single field for Parent name. In edit mode it shows the Parent name field and the drop down choices are names.

But on a copy of the app moved into my EA testing Realm, in edit mode it shows the [Record ID#] which is clearly meaningless to users.

I suggest that there will be many many apps out there where the users, like myself in my early QuickBase (one word) days, didn't "get" Proxies and in fact they confused the heck out of me because when you build a relationship, it assumes that the very first lookup field is the reference Proxy and sometimes that was a not a good proxy or else i would end up with both the Proxy and the related parent on the same form in add/edit mode (which does not work to have the same field on the form twice in edit/add mode).  So I avoided using them.

So my point is that if GA will show the Record ID and behave differently than the current behaviour, then that will break a lot of apps and cause a lot of support calls.

09-27-2018 16:59

@Mark/ Quick Base Coach, 
If that's the field which is on the form, shouldn't it be the field which is displayed on the selected value? When I started using Quick Base I found that having a value which wasn't the one on the form displayed very confusing.

Sam Jones
Quick Base Product Manager

09-27-2018 16:58

@Alex, We've got a fix for clearing values coming in the next release.

Sam Jones
Quick Base Product Manager

09-25-2018 20:04

We're having the same issue. Dependent values are getting stuck even when the user tries to clear them before re-picking.

This is why beta/EA is great, as you say. Two weeks ago it barely worked at all!

09-25-2018 20:02

I'm on the Early Access for my own Developer's Realm and working though a few issues on the Conditional Drop Down field types where the field [Related Parent] is on the form (as opposed to the more correct Proxy field).  But that is what EA is for, to work though less common use cases which did not get caught in their QA.

But yes, it will be great once it gets into General Availability.

09-25-2018 19:56

It's SO good.

09-24-2018 11:54

Great job. This has been on the wish list for a while :) I think it will be a welcome change to a large number of your customers.