Independent screen configuration for collection in Pages

Hi All,

I have run a informational database using Glide Apps for sometime now and with the transition into Glide Pages I am wanting to work on transferring over my project to Pages.

However, I am running into an issue where I cannot create an independent screen configuration for a collection. I have 160+ records recorded in my Resources sheet. In Apps I’m able to run an independent screen configuration which helps for when I want to design custom screens for a particular resource. I make a master layout and copy and paste them across all 160+ pages for consistency, then I’m able to edit each one and customize it with richer detail for records that I have additional info for.

In Pages when I click either New Screen or Details Screen for this item is copies the exact layout for each item in the collection. This means I would have to add 160+ containers with conditional visibility to filter the view for each record. This is not helpful.

I tried thinking of other methods (maybe creating 160+ pages in Pages and then having glide create the URL for me and then having the collection action pull in the correct URL) but I’ve ran into issues (in this instance the URL is pulled up in a new tab and not the current tab so it causes UX issues).

Any ideas on how to get this to work?


You maintain 160 different independent screens? I think most people would do 10+ at most. Can you explain your use case some more? What’s different between each screen that it needs to be independently designed? I would hope that that there is maybe a better way.


Hi Jeff!

Thanks for replying :pray:

I built this whiteboard to help explain how my app works and my current problem

My app is at We aggregate LGBTQ+ resouces for LGBTQIA+ individuals and allies in Utah. We originally launched our project with no independent configurations and just had each resource profile comprised of data from a Resources table. Eventually we wanted to customize each profile and add speciality information and make each profile more engaging (add video, custom lists, audio, embeds, etc.) This means users would go through our flows and then either see a custom built profile (ones we build for our community resource partners) or the default one (standard format) – see the first flow chart in the whiteboard.

We originally were using conditional formatting (WHERE resource = 'Encircle Provo) on each screen to get in the custom info, but this lead to an absurd amount of objects on a screen. — see Custom Pages without Independent Screen Configuration on whiteboard.

So instead we decided to convert the entire app to independent screen configurations anywhere there was a custom profile at the end of a flow. This allows us to limit the number of objects and not have to use conditional visibility.

If you look at the examples on the whiteboard you can see our Custom Pages are more engaging and have video, multiple images, custom collections, and more while maintaining a short and clean object list.

The issue with Pages is that I can’t do the same. Because there is no option for an independent screen configuration I would overwhelm my objects list with custom containers for each speciality profile.

Hopefully seeing the website and seeing the whiteboard help clarify my issue.

1 Like

So is it safe to assume that much of the content on your custom pages is not data driven…meaning a text component or a video component has the text/link directly entered into the component instead of pulling it from a column in the table? I guess what I would do is make everything data driven, so you could have a general template that’s the same for every page, but pulls data from the table. Normally, if a column is empty, the component won’t show on the screen, so there wouldn’t be a need for any conditions. Just having a particular column populated or not would be enough to make certain components display or not. I guess that’s how I would do it so you aren’t maintaining so many different screens. You only maintain one screen, but strategically fill the data to get different looks.

Another thought would be to make use of the rich text component. If you are good with markdown or html, then a lot of the content can be built into a single text column, but displayed in a rich text component, which will render markdown into html and render html nicely on the page. A bit more work, but another option.

To me, maintaining the design side of that many screens would be a lot of work…especially if you need to go back and add or change something on each and even one of them. Designing a single screen and the structuring the table in such a way that everything can be data driven, would be better in the long run. Maybe you would need a handful of visibility conditions on. certain components, but I think it would be minimal if done right.