What is a cascade?

A cascade is what happens when a single trigger (one sale, one referral, one form submission) pays out to more than just the collaborator who caused it. Instead of crediting only that person, Siren walks the collaborator group they belong to and emits a credit at each layer above (or below) them. The triggering collaborator’s manager earns something. Their manager’s manager earns something smaller. And so on, until the cascade hits a layer you’ve set to zero.

This is the “tiered commissions” or “override commissions” model that sales orgs and brokerage networks rely on. Siren’s framing is more general, covering any per-trigger fan-out across a hierarchy, but if you’ve been searching for “override commissions” or “tiered commissions,” cascades are the feature you’re looking for.

How it works

Cascades depend on three things working together: a hierarchical collaborator group, a cascade calculation strategy, and per-layer point values.

First, you bind a program or distributor to a collaborator group that has structure. A flat group won’t work, because there are no layers to walk. You need a linear chain (ordered by position) or a parent-child tree.

Then you pick a cascade calculation strategy. Two ship today: upline cascade walks toward the top of the chain (people above the triggering collaborator), and downline cascade walks toward the bottom (people below them). The picker on the program or distributor edit screen hides cascade strategies when the bound group is flat, because there’s nothing for them to walk.

Finally, you set per-layer point values: pointsAtLayer1 through pointsAtLayer5. Layer 1 is the nearest neighbor in the chosen direction, one step up for upline, one step down for downline. Layer 2 is two steps away. The cap is five layers.

When a trigger fires, the cascade walks the group from the triggering collaborator outward. At each layer, it emits one credit per collaborator at that layer, using the points you configured. A layer set to 0 (or left unset) stops the cascade, and nothing past that layer gets credited. That’s the lever you use to say “only pay three deep.”

Two behaviors are worth pinning down. The triggering collaborator is never credited by the cascade. Their direct payout comes from a separate calc strategy (usually fixed) bound to the same program, and the cascade only handles the people around them. Inactive peers (suspended or deleted) are skipped and earn nothing, but the cascade does not renumber the layers around them. A suspended person leaves their layer unpaid, and everyone else keeps their own layer and rate. So if the person at layer 1 is suspended, layer 1 pays nothing, and the next person up stays at layer 2 and earns the layer-2 rate. They are not promoted into the empty slot. In a parent-child tree, where a layer can hold several peers, one suspended peer does not stop the others. The remaining active peers at that layer still earn the per-layer rate.

A concrete example

Picture a four-person linear chain: chain-one at position 1, chain-two at position 2, chain-three at position 3, chain-four at position 4. Lower position numbers are higher in the chain, so chain-one is at the top and chain-four is at the bottom.

You bind a program to this group with an upline cascade and the following per-layer points:

• pointsAtLayer1: 100
• pointsAtLayer2: 50
• pointsAtLayer3: 25
• pointsAtLayer4: 0

chain-four makes a sale. Here’s what the cascade emits:

• chain-three earns 100 points (layer 1, one step up from chain-four)
• chain-two earns 50 points (layer 2)
• chain-one earns 25 points (layer 3)
• chain-four earns nothing from the cascade

If chain-three had instead made the sale, the cascade would only have credited chain-two (100) and chain-one (50). The cascade stops when it runs out of collaborators above the seller.

Now flip the direction. Same group, but the program uses a downline cascade with the same per-layer points. chain-one makes a sale. The cascade walks down:

• chain-two earns 100 points (layer 1, one step down)
• chain-three earns 50 points (layer 2)
• chain-four earns 25 points (layer 3)
• chain-one earns nothing from the cascade

The mechanic is symmetric. Direction is just a setting.

Cascades and pools

The per-layer numbers are scores, not dollars. They feed into whatever incentive structure the program (or distributor) uses to turn scores into payouts.

With a fixed-per-incentive structure, each layer’s points become a literal dollar payout, so 100 points might mean $100, depending on how you’ve set up the math. The scores act as the payout amounts directly.

With a performance-weighted pool, the scores become weights for splitting a fixed pool. The 100/50/25 from the example above becomes a 4:2:1 split, where chain-three gets four shares of the pool, chain-two gets two, chain-one gets one. If the pool is $700, that’s $400, $200, and $100.

The point is that cascade scores are a layer in the calculation, not the final answer. The program’s distribution structure decides what to do with them.

When to use a cascade

Reach for a cascade when a single trigger should fan out across several people rather than crediting only the person who caused it, and when the reward depends on each person’s distance from the trigger. The classic cases are multi-tier sales organizations, where a rep makes a sale and their manager and regional director each take a smaller override. Brokerage and agency override structures follow the same shape, with senior real estate and insurance brokers earning on the production of the agents they oversee. Channel and partner hierarchies fit too, where a partner manager earns an override on the partners they manage. Management and mentor overrides, where a team lead earns a slice of every sale someone on their team makes, and team-based commissions that tie a leader’s pay to their team’s results round out the family.

If you only want to credit the person who caused the trigger, you don’t need a cascade. A fixed calc on a flat group is the simpler tool. Cascades are specifically for the fan-out cases.

For developers: A cascade is a calculation strategy that walks a collaborator group’s structure and emits one credit per layer. See the custom calculation strategies extension page for the full API, and the collaborator group events reference for the binding and structure events a cascade depends on.