Forum Academy Marketplace Showcase Pricing Features

Challenge for bubblers - Multilevel Logic

Hey guys and gals!

I’m building a hierarchy system and I ALMOST have it working perfect! I made the following data types:

Handle Name
Handle Number

When a user creates another user the new user is given the parents handle name and the parents handle number +1

Users can only see them self and users with handle numbers greater than there own handle number which would be the people that were signed up after them.

The problem is this…

if the top layer signs up two unrelated groups, they both have the same handle number, which means they can see each other’s groups and the groups those groups put under them… It needs to split to be unique to each downline…

I want to figure out a way to assign letters(maybe?) if two or more groups are on the same level…

Really lost on how to achieve this and it’s pertinent to my project. Essentially, the hierarchy is everything…

Any thoughts?

Why not have a field on the user called “parent,” and limit visibility by the parent?

It needs to go all the way up the the line… so there would be parents of parents… not sure how to do this programatically.

Some distribution groups have 20 groups under them and each of those has a couple under them… I need to make sure the top see’s everything below them, but no one can see above or next to them… would the your logic work for this?

If the depth and parents are the same for any two nodes, they are on the same level. To find the smallest subtree of two nodes, intersect their path from themselves to the root. The number of parents that intersect indicate how deep the common parent is. Look up trees/graph data structures to see what more you can do with them.

I dunno, I was just spitballing ideas :stuck_out_tongue:

Is something like this possible to be programmed on bubble?

I have:

First layer = 1
Second layer = +1 (2)
Third layer = +1 (3)

1 can see everything greater than 1, 2 can see the numbers greater than 2, 3 can see the numbers greater than 3 and so on…

The problem is if there are two 2’s (second layer) that are unrelated, they see all the 3’s under them instead of only seeing their 3’s

If I had another identifier per level that counted on it’s own it would work perfectly…

2a see’s all the 3a(x)'s
2b see’s all the 3b(x)'s
…and so on…

Totally doable in Bubble. Just make sure you store all necessary data.

That other identifier would be the parent or parents of that node. On search or evaluation, just check that the parent node is appropriate (e.g. 2a can only view nodes at level 3 where it is the parent of the node at level 3; this would exclude those in the other subtree).

This article will show you how to approach this so it’s scaleable. (

Remember, it’s all about happy little trees


Haha! Thanks, Bob Ross!

So I’m going to try to do this by having a number data type I call horizontal and a number data type I call vertical… When user 1 (top layer) adds a user the new user (layer 2) will be vertical +1 and horizontal +1 AND the current user will change horizontal +1

So Vertical 2 can see all verticals greater than 2 but will be constrained by horizontals that are = to 2 (only himself and those he added underneath)

the next person user 1 adds will also be vertical 2 HOWEVER they will be horizontal 3
and will be able to see all things greater than 2 constrained by it horizontal number, to segregate from others at the same level

I think this may work…

Nope… I keep bumping into myself on level 3

Why not just use the parent to distinguish which subtree a node is in? The parents of the two V3H4s are different.

I’m trying man, what would be the best way to do this?
When the parent creates a new child I can make a data field type called parent and store it by “current users name” to the child … but what would be the best way for the child to reference that to separate itself from the other H3V4?
How would you do this if you were in my position?

When creating a new a node, I would store it’s immediate parent in a field. Parent in this case is in itself an object as well, not the name of the user (which can be retrieved by seeing who created the object). To see if a node is a sibling to two different nodes on different subtrees at the same level, you can see which of the two nodes share the same parent. I would also store the child’s parent’s parents + the child’s parent in a list. The list of parents is useful to store the path from the child to the root.

Got it… I’m on it.

Pretty sure I did it! Thanks so much for your help! When a new user creates a sub user I need it to credit everybody above but not cross… so here is what I did (the family tree data type keeps adding every layers current user to a list)

I give every top layer a unique handle to begin with so between the handle, the H the V and the family tree I don’t see it possible for there to be any data cross over possibility when users are adding users who are adding users under them and so and so forth… Everyone will be credited properly for their downlines



Out of curiosity, what will you use it for?

1 Like

I have built a CRM for a sales company, where as every rep that brings a rep on underneath them gets credit for that rep ($)… in some cases the sales force is 20 layers deep and each layer can be as many as 20 people wide… For the purpose of organization and financially tracking I’ve had to automate this hierarchy that grows daily. I still havent gotten where I want it but I’m doing my best!

Should “hrizontal number” be “horizontal number”?

I don’t fully understand what solution you picked.

An idea I had was that each person can have a field for “my parents” or something like that. You just copy your parent’s list of parents and add your parent to the end of the list.

So the first person will copy a list with zero entries and add nobody to it.
The 2nd level will copy a list of zero and add the first person to the list.
The 3rd level will copy a list of 1 and add their own parent to the list.

That way each person will have a list of their parent, and their parent’s parent, and so on, all the way back up the tree. If you want to let them see someone else in the tree just check that their pedigree list contains the appropriate name.