Mastering the Mighty Single Value → WHOLE ROW

Learn to master the Single Value → WHOLE ROW feature

Use this feature to easily link to the details screen of a:
:point_right: home screen…
:point_right: sign up form…
:point_right: about page…
:point_right: …and more!

Thanks to @Darren_Murphy for one of the ideas presented in this video!


Never occurred to me to add those sv->whole row columns to the User Profile table, but it’s so obvious when you say it. I’ve been in the habit of adding one to every table where I need to use it. Time to change habits :slight_smile:


Very nice Bob. Instructional, clear, and eye-opening as always.

1 Like


1 Like

Likewise. :man_facepalming: Didn’t cross my mind to use the user table.

I’m already in the single row table (tab source table) when I trigger Add mode in my custom form. I only needed a single value → Whole Row when I open the custom form in Edit mode. So I guess I didn’t waste too much time. :stuck_out_tongue_winking_eye: But good to know if I need to call the form from more places.

1 Like

Great video, as always.

I do have a single record “control file” which contains various information used elsewhere.

As always, I seem to push the limits of Glide. I tried “whole row”, but unfortunately, the new field does not appear everywhere i’d used the individual fields. In a custom action, I cannot set the column value using that field. It doesn’t show up.

I cannot set “*control → App Price” for example:

That new field is not in the list:

Hmm, strange I also don’t see it when setting properties on an image component (the image or any of its properties).

As long as the source sheet for the screen is the one that has the single value, it should work. Again, life will be easier if the single value → whole row is in the user’s table:

Yes to both. The value is in the Users table and the source for the screen is in the users table.

On the Add Row action, I can choose other values from the User table, but *Control does not appear in the list.

Looks like Control is referencing a whole row. If you want to use a column from that row in an action, you’d need a lookup on top of it to fetch the column value. Bob mentions that in his video.

Right… whole row = relation. If ever Glide allows us to have inline lookups (vote here: Select values from relations just like "User >" (Inline Lookups)), then what you’re describing would be possible, theoretically.


Hi Darren,

I think what Bob just said about selecting values from relations is the issue – because in my “add row” action, I don’t even see it as a relation, and it does not show up when I select “User Profile”:

Yes, Bob said the same thing as me - using different words :slight_smile:

You’re looking for functionality that doesn’t exist. (We all wish it did).


Seeiing is believing! Now I understand it better than ever! Thanks @Robert_Petitto !

1 Like

Glad it helped!

Love it but just find myself avoiding custom forms wherever possible because of update fear :cry:

In the contact us example, how many updates would that use?

I do the same. This is just one use case. To answer your questions, I guess it would depend on how many fields they needed to fill out.

Just to chime in. I use a custom form because I have a particular use case.

  1. With one of my choice components, I need to write both the visible description of the choice, as well and the underlying number. So in my example below, I need to save both the Lesson Length Name as well as the rate that’s associated with that Lesson Length. For me lesson rates can change in the future, so to avoid affecting older lessons when rates change, I can’t use relations to pull in a rate based on length.
  2. I use that underlying number as part of a live calculation. This is so the user can verify in real time if everything is correct before clicking on submit. Each user can have different rates, and rates can differ per user, so everything needs to be dynamic.

In some cases, I also allow the user to enter a custom rate.

So in my case, a custom form is the only viable option, since I can’t achieve the same functionality with a native form. It also allows for some more robust validation before allowing the user to submit a form.

Fortunately for me, this app has about 1.5 users, so going over usage limits is not a big concern, but I understand where it can be something to consider. There are use cases for custom forms, but if they can be avoided, I do agree that a native form is the way to go.