If you create a custom collection source to table A, then the components that make up this custom collection can be configured with visibility conditions based on columns in table A. This is normal since the collection is a representation of table A. Sure, you can pull into table A data from another table with relation, query or single value columns, but basically the custom collection represents table A.
What do you mean?
To me, there is no such thing as a “parent” collection. Instead, there is a tab whose layout is attached to (“governed by”) a single row somewhere in one of your tables. This table can be the Users table, a general Configuration table (often my preference), a dedicated 1-row table just for that tab (I used to do this but I’ve now moved away from this), or often builders chose a table related to the “topic” of the tab (for example, if the tab mostly shows employees, then the data source would be the Employees table). If no filter is applied, then by default the single row chosen as the source of data for the tab is the first row of the table.
On a tab or any screen for that matter, you can then add collections that have their own data source. There is no hierarchy of collections, there is no parent collection.
It makes a lot of sense. When you select a collection, you can
- Determine its visibility conditions, and these conditions are based on data of the single row data source of the tab or the Users table.
- Filter the data shown in the collection and the filtering conditions are based on the data in the data source of the collection or the Users table.
I don’t really understand this stuff all that well, but this is where in Glide there is a game of accessing data of one table from another table. And you do this with relations, query or single value columns. Also, in options when you set visibility or filter conditions, the current data source is available as well as the Users table. So in a way the Users table can be considered a master table. You can leverage that by putting “general” data for the entire app in there. I personally am uncomfortable with this approach because I get very confused when my data is not clean (what I consider not clean): user-related data is user-related and app-related data is app-related, and I dislike mixing the two.
Remember: use relations, query or single value columns to access data from another table without having to copy it. And then once in a while pinch your nose and hope for the best 
(and hope you won’t have to review it later)