Why does every new "Custom Screen" page I create have to have a page source?

I often find myself trying to create a dashboard that uses a variety of components that reference different tables in my data. However, I’m restricted to only referencing data that I’ve selected as my “page source” (see pic 1). I wish I could choose a different table other than my page source, similar to when adding a new collection component, I can choose which table i want to reference (see pic 2)

Maybe I’m incorrectly using tables in the data tab?


The fundamentals of every screen in your app is that they are attached to a specific row in a specific table. There is no getting around that fact.

You could create a separate single row table solely for dashboard screen. If you need access to data in other tables, there’s a variety of methods.

  • You could use Query or Relation to link to certain rows in other tables. You can then use the Query/Relation as the source of charts, collections, or other things on your screen.
  • You could add Lookup, Single Value, Joined List, etc to retrieve specific values directly from a table or from the Query/Relation.
  • You can use a custom collection as a window into other tables and then add any components you want into that custom collection container.

There’s a lot of ways to do it. It just depends on what kinds of data you are trying to bring into your dashboard screen and how you want to display it.

1 Like

Thanks for your detailed answer! Yeah, I ended up just creating a relation but that’s slowly becoming a game of creating more and more relations just to show a single “Big Number” on a page lol.

I’m curious why the Glide team decided to take this approach? Airtable Interfaces allow you to reference any row/column in any table and that feels like a more natural approach (to me at least). I feel like it’s easier to explain to new users as well, kinda like how a spreadsheet allows for cell referencing with “=”

^Airtable Interfaces

I don’t know how they came up with their original design, but originally apps were built only on top of google sheets. Essentially everything in a Glide app was and is data driven, so it it just makes sense to have screens that are actually connected to that data to display it. Glide has organically grown a lot in 5 years. If it’s any consolation, Glide used to have some screens that could only show a list (collection) and no other components. Now everything is a detail screen that can be customized with several different components.

Well the question becomes complicated. If you are pulling data from another table, which data is it? Does it come from the first row? Last Row? Third from the top? A row for a certain user or role? A relation or query is a way to specify which row or rows you want to look at in another table? What if you have custom filters on your dashboard? Then how would you specify which data in other tables you want to display?

A relation isn’t needed for everything. Maybe a Single Value column is sufficient. Maybe just a Lookup column, or maybe a Joined List column. Or like I said, you could shortcut it by using a custom collection directly on the screen.

Simple fact of the matter is that Glide is not Airtable. I could probably keep going on and on with different responses regarding why it works this way, or why you want it to work this way, but it’s probably easier to offer suggestions if you have a specific use case that you can describe. You mention trying to get a Big Number component to show a value from another table. Can you describe what you are getting from that other table? What does the number represent from the other table?


Interesting to learn the Glide history! Didn’t know apps were originally built off of only Google Sheets but that helps me understand where we are today.

I agree with what you’re saying, there are definitely many different ways to solve the same problem in Glide. However, I can’t help but think this specific “page source” restriction doesn’t feel ideal? Perhaps I lack a good understanding in how to construct good data model for the type of app I’m making?

For example, A Glide user has some data in multiple tables and they want to show some of that data in a layout and let the user interact with it. Why force them to somehow bring the data they’re interested in showing into another (potentially irrelevant) table just because they selected it as the page source? Especially, when they can just present it directly in the view (similar to a collection allowing me to present any table I like).

Some context into what I’m building:

A student planner for university students who want to track their courses, assignments, grades, notes, and budget. Each of these things I’ve mentioned above have a table with associated columns.

I’m trying to build a “dashboard” view for a student who wants to see the courses they’re currently enrolled in (card view) and then I went to add a “Big Number” at the top that shows their budget left for the month or their GPA, or some other metric that isn’t really related to the original page source - in this case “Courses”.

I want my tables to be very clean and not have random columns I created just because I want to show something on a page. Maybe, that’s my issue? Curious if you have any good recs for learning about data model design in Glide?

Back then we didn’t even have a data editor. Everything…and I mean everything…was done in the google sheet, including building relations and any calculations using sheet formulas. Fun times.

I assume a Student is a user of your app? If so, they should have a row in a user table I assume. If things such as Budget or GPA are available in the user table, then you should be able to directly point a component at the user profile row without having to first bring it into another table. Access to the user profile from anywhere is one exception because it’s always one single row and it’s always predictable. Maybe it’s better in your case to create a tab sourced from the user table and filtered to the signed in user’s row??? Then you don’t need an extra table and I would guess that some of the information on that dashboard would come directly from the user’s profile row.

Again, a custom collection is another option if you want to refer to another table and still be able to add components referring to that table, without the need for extra relations/lookups and such.

Some of us create tables that aren’t even designed to hold data. In those cases, all or most columns are computed columns or user specific columns that only store data for a short amount of time. We use them to perform various calculations, build custom forms, transpose data, and various other things. I love building entire screens or entire apps that function from a single row table, even if there are supplementary tables that feed data into the main one. We call these helper or working tables. Once you realize the power of everything you can do by linking multiple tables together and bringing data from one table into another…your world opens up quite a bit.

I think you may be overlooking the full potential of what’s possible because you haven’t needed it yet. I would hate to build out a full screen, then realize I need a little bit of background processing or calculations that can only be performed in a table, and then have to rebuild the entire screen again to attach it to a table.

For database structure in general, I probably follow the rules for data normalization.

To best learn Glide, there’s the Glide University, Glide Docs, and Help Center. Plus a ton of resources in this Community Forum where you can just ask for help on anything and someone should be able to help or guide you.


This is solid advice, YouTube video was really good too, helps a lot with creating legit tables. I’ll take a look at the docs and university stuff too.

I think my view on tables has changed to being less a store of clean data and more so a way to compute the data I’m looking + storage.

Thanks for the info!