Downline cascade calculation

Downline Cascade credits the collaborators below the triggering collaborator. When the trigger fires, Siren walks down the bound collaborator group and emits one score per layer at the configured per-layer amount.

How it works

A cascade starts from the triggering collaborator’s position in the group and walks toward the leaves. The triggering collaborator is never credited, only the people below them.

Each layer is 1-indexed. Layer 1 is the direct downline: the next position down in a linear chain, or the immediate children in a parent-child tree. Layer 2 is the layer below that. The maximum is layer 5.

For each layer the cascade visits, Siren reads pointsAtLayer{N} from the calc’s configured args and emits one credit per peer at that layer for that amount. In a parent-child tree, layer 1 can include several peers. Every direct child of the trigger gets a layer-1 credit. The per-layer score is per peer, not split across the layer.

A 0 (or unset) value at any layer stops the cascade at that point. If pointsAtLayer3 is 0, layers 4 and 5 never run, even if they’re configured. Layers are counted by distance from the trigger across the whole tree, so a 0 at a layer stops every branch at that depth, not just one.

The per-layer value is a score, not a dollar amount. It sets each collaborator’s weight, and the program’s incentive turns those weights into the actual payout. Pairing the cascade with a performance-weighted pool splits a reward pool in proportion to the scores, so the layer values decide each person’s share of that pool.

Inactive peers (suspended, deleted, or otherwise excluded) are skipped without consuming the layer slot. Other peers at the same layer still get credited at the per-layer rate.

The results flow through the same engagement and metric pipelines as Fixed. Downstream attribution sees a set of credits instead of one, but the shape is identical.

If the bound collaborator group does not expose layers (a flat group, for example), Downline Cascade has nothing to walk and fails closed. It emits nothing and never falls back to a single Fixed credit. The picker hides Downline Cascade when a flat group is bound, so you should not reach this state in normal use, but the picker is the only guard. If a cascade is already saved and the bound group is later changed to flat, deleted, or unbound, the calc keeps the cascade strategy and pays out zero rather than reverting to Fixed. See Cascade troubleshooting for the states that produce zero payouts after configuration.

When to use it

Use Downline Cascade when the people below the trigger should share the payout. Common cases:

• Awarding a bonus to a team’s members when their team lead hits a milestone.
• Team performance payouts where a manager closing a deal pushes a slice to each team member.
• Override-style bonuses where a result at the top of a team distributes a share to each level beneath it.

Downline is less common than Upline Cascade, but it fits compensation plans that reward leadership through team distribution, when the goal is to motivate the layers under a top performer rather than the layers above a producer. If you’re not sure which direction you want, read Choosing a calculation strategy.

Configuration

Five integer args: pointsAtLayer1, pointsAtLayer2, pointsAtLayer3, pointsAtLayer4, pointsAtLayer5. Each one sets the score for one peer at that layer. A 0 at any layer stops the cascade at that point. Set layers you don’t want to use to 0.

The picker on the Programs Edit and Distributors Edit screens only offers Downline Cascade when the bound collaborator group provides layered walker steps. Flat groups don’t, so the option stays hidden. Linear chain and parent-child both qualify. See Why some calculation methods disappear for the matching logic.

The program side and the distributor side differ in where the bound group and the args live. On the program side, the bound group is read from the program config (config type program, key collaboratorGroupId) and the per-layer args are stored on the program engagement type (config type programEngagementTypeArg). On the distributor side, the bound group is read from the distributor config (config type distributor, key collaboratorGroupId) and the per-layer args come from the distributor metric type (config type distributorMetricTypeArg). The arg keys are the same on both sides (pointsAtLayer1 through pointsAtLayer5), so a metric-side cascade needs a group bound to the distributor and is configured on the distributor’s metric type.

Worked example: chain

A 4-person linear chain, ordered top to bottom:

• chain-one, position 1
• chain-two, position 2
• chain-three, position 3
• chain-four, position 4

The program uses Downline Cascade with pointsAtLayer1: 100, pointsAtLayer2: 50, pointsAtLayer3: 25, pointsAtLayer4: 0.

chain-one makes a sale. The cascade starts at chain-one and walks down. chain-two is layer 1 and gets a score of 100. chain-three is layer 2 and gets a score of 50. chain-four is layer 3 and gets a score of 25. Layer 4 is 0, so the cascade stops. chain-one, the seller, gets no score from this calc.

Worked example: tree

A 7-person parent-child tree:

• alex (root)
  • rae (child of alex)
    • ivy (child of rae)
    • jude (child of rae)
    • kit (child of rae)
  • ravi (child of alex)

The program uses Downline Cascade with pointsAtLayer1: 60, pointsAtLayer2: 30, pointsAtLayer3: 0.

alex makes a sale. The cascade walks down from alex. Layer 1 is the direct children, rae and ravi, and each gets a score of 60. Layer 2 is rae’s children: ivy, jude, and kit each get a score of 30. Layer 3 is 0, so the cascade stops. alex gets no score from this calc.

This is why per-layer values are described as “per peer per layer” rather than “per layer total.” A layer with five peers emits five separate scores at the per-layer value.

If you need a refresher on the underlying mechanic, see What is a cascade.