🔥 Add Components to User Profile!

I agree with @sardamit. I haven’t done it but it was my first thought.

1 Like

Would have to be a link to screen with entry fields I guess.

Add a button linking to screen, doesnt works in mobile

1 Like

I have a client that didn’t want a separate myProfile screen. Wanted a list of all favorited items across the app:


That’s neat!

Right…I let Glide know about this bug too.


I’m starting to really like this new setup, but really, the thing it needs is the ability to edit User Profile fields straight from this screen. Linking to a screen with text entry fields, etc. isn’t the best process and allows for some fields to be blanked out entirely (can’t be made “required” since they’re not opening in a form/edit environment). I’ve tried setting a minimum length of 1 to my text fields, but the Back button still allows someone to get around that condition and a user could end up leaving their name blank, for example. A true Edit button (or Edit Item Action — even better) would be the best way to make this new setup the only User Profile area anyone should need.


Yeah, not yet too

1 Like

A feature request would be Navigate to Tab be able to go to User Profile screen.

This way we can create actions to the app get there after an onboarding screen, for instance


I have found that my users rarely hit the hamburger menu and I question if users would hit the user profile within unless there was a call to action like “Edit Profile”.

p.s. Given Glide’s non-human readable URL structure I am not sure if I can quantify that observation in google analytics.

1 Like

Is it possible to make a tab the same as ‘user profile’ ?

1 Like

I keep on thinking that it may be difficult for users to find this screen.

1 Like

Link to screen isn’t working. Independent screen configuration per item for details isn’t showing Independent configuration.

1 Like

Agree. I had to use CSS to hide the back button and instead put in a Save button of sorts but even then users could start to edit the profile and then quit the app and their changes would save.


I’ve done the exact same thing, but now I’m trying to make a template — and can’t use CSS if I want it to be accepted. Hopefully the ability to edit from that screen is in the pipeline.

@shchc @Robert_Petitto I’ve started to do a lot of “custom forms” that use temporary columns. (It hasn’t been necessary, but I’ve been setting up these temp columns as user specific columns, because the icon is blue in the data editor and it makes it easier for me to tell that these are my temporary columns.) I’ve done these custom forms largely to avoid the weirdness of the form pop up modal with the android back button, and I prefer to use a floating form button as the submit, compared to the the default submit button at the top right of the screen. When going to this screen, I usually set up a combo action to first pre-fill any temp columns that need to be filled first (but can still be edited by the user), then execute the link to screen action to open the screen. You could do the same thing by duplicating all of the editable user profile columns to act as temporary columns, have an edit button with a set column action and a link to screen action, let the user make their changes, then have a save button with a set column action to write all of those temp column values back to the normal profile columns. One advantage of this is a little more flexibility in performing realtime calculations if needed, and along with the new hint component, the ability to set up more robust error checking of data. Yeah, you lose the ‘required’ field ability compared to a form or edit screen, but you can also hide or show the save button depending on if all requirements are met to submit/save.

One awesome advantage I discovered last night for my app is that I always had the need to save a Lesson Name. That lesson name also has an associated rate attached to it. Unfortunately, I had to get the rate through a relation once the form was submitted, but if that related rate would ever chang, then it would screw up any old lessons that were charged under the old rate. That’s because a choice component can’t write multiple values to multiple columns, so I had to either store the lesson name or rate. I chose name. Now with the solution above, I can use a relation against those temp columns in real time to always get the lesson rate once the lesson name is selected. This allows me to show the rate in real time before my “custom form” is submitted. This also allows me to have that date available to permanently write the Lesson Name as well as the Rate to the sheet through an Add Row action. Now I won’t have to use a relation to get the associated rate. It will be written and saved permanently.

In the end, this still gives users a chance to back out of any changes. They can skip hitting the Save action button and just got the back button without committing to any of the changes.


I do this all the time and never thought to do it with the user profile columns. Nice workaround!

Your last paragraph about lesson rates is something I just stumbled upon as well. Depending on the situation, you can eliminate array formulas via math columns of those temp columns and then writing them to the actual columns via add row.


These are really cool ideas… Going to have to do some playing!


Would definitely add a little efficiency to not have the app attempt to calculate every time the app is loaded. That’s my main goal right now. I have a lot of computed columns and large sets of data that are starting to slow loading times down. I’ve been trying to find new ways to streamline parts of my app because there are a lot of computed glide columns processing a lot of data and it takes a few seconds for that to happen when the app is opened initially.

That makes a lot of sense then in one of my apps. I have 12 Rollup columns over a few thousand rows and the app is VERY slow to open.