MLM Genealogy Software

The two decisions that determine everything

A genealogy view is a tree of potentially hundreds of thousands of nodes, each carrying aggregate numbers computed from everything beneath it. There are two ways to build it, and the difference only becomes visible once you have a real organisation.

Load the tree, or load the node. A screen that requests a distributor’s downline and renders it works beautifully in a demo with two hundred seeded positions. At fifty thousand it takes fifteen seconds and freezes the browser. The alternative is to request one node and its immediate children, and to fetch deeper levels as they are opened — so a query costs what is on screen, regardless of whether the organisation has a thousand positions or a million.

Compute volume on view, or on write. Group volume is the sum of everything below a node. If that sum is calculated when the tree is displayed, every node expansion is a recursive aggregate over a subtree, and the cost compounds with depth. If it is maintained as orders post — each order incrementing the roll-ups of every ancestor — then displaying a node reads a column.

Both decisions are made here in the second direction. The result is the figure in the specs above: 250,000 positions, depth 60, sub-second subtree loads. Ask any vendor for their equivalent number and the conditions it was measured under, because “real-time genealogy” is claimed universally and means nothing.

Two trees, and why it is not a redundancy

In a unilevel, placement and sponsorship are the same relationship and one tree suffices. In a binary, matrix or forced matrix they diverge immediately:

Both are authoritative for their own components, and neither is derivable from the other. This is covered from the compensation side on the binary plan page; from the genealogy side it means the tree view has a toggle, and every node shows its parent in both structures.

What you can put on a node

A genealogy view is only useful if it shows the number you are currently investigating. The node label switches between personal volume, group volume, leg volume, rank, activity status, join date, last order date and pending qualification — without reloading the tree.

That list is deliberately mundane, and it is what turns the tree from a diagram into a tool. “Show me this organisation coloured by last order date” answers a retention question in one screen that otherwise takes an export and a spreadsheet.

Any subtree exports to CSV with the chosen columns, subject to the operator’s own visibility permissions — so an export cannot leak contact details that the interface would have hidden.

Moves: legitimate, and deliberately hard

Position moves are necessary. A placement error caught in the first week, a documented distributor transfer, a duplicate account merged. They are also the most disputed administrative action in this industry, because moving a position changes the income of everyone above it.

The controls, therefore:

• a mandatory reason on every move,
• an approval queue with a second approver where you configure one,
• a full audit record — who, whom, from, to, when, why,
• and no retroactive recalculation. A move affects future runs. Closed periods stay as they were paid.

That last rule is the one worth checking with any vendor. A system that recalculates history after a move will silently change what a past statement says, and the first person to notice will be a distributor whose commission for last March is now different.