Configure cascade payouts
Bind a collaborator group to a program or distributor, pick a cascade calculation strategy, and see per-layer payouts fire.
Requires Siren Pro
Last updated: June 3, 2026
You already have a CollaboratorGroup with a linearChain or parentChild structure. This tutorial wires it into a program so a single sale pays out across multiple layers of the chain or tree. By the end you’ll have triggered a real engagement, watched Siren produce one credit per layer, and seen those layered credits land on the right collaborators inside the program’s obligations.
Before you start
You need a few things in place before the walkthrough makes sense:
- Siren Pro is active on the site.
- A CollaboratorGroup with structure
linearChainorparentChild, already saved. If you haven’t built one, follow Create a collaborator group first. - A program you can edit. A fresh test program is fine, pick one you don’t mind reconfiguring.
- At least one engagement type the program uses (Sales, Manual, Coupon Code Used, whatever you plan to trigger).
The same flow works on distributors too (the last section covers that), but the main walkthrough is on the program side because most operators start there.
Step 1: Bind the program to your collaborator group
The cascade needs a group to walk. That binding lives on the program edit screen, in the Collaborators section.
Open the program for editing
Hover over Siren, click Programs, then click the program you want to wire up.
Scroll to the Collaborators section
You'll see two tabs: Direct and Group.
Switch to the Group tab
Picking the Group tab clears any direct collaborator list, and switching back to Direct will clear the group binding. The two are mutually exclusive on purpose: a program either pays its own list of collaborators or it pays through a group. On a live program, do not toggle tabs just to look. Switching is what clears the other side, so only switch when you mean to change how the program is bound.
Pick your chain or tree group from the dropdown
Only CollaboratorGroups you've created appear here.
Save the program
The binding writes a config row tying this program to that group's id.
That’s all the binding takes. The interesting part is what it unlocks in the next step.
Step 2: Pick a cascade calculation method
Reopen the program for editing. Find the engagement type whose calc you want to change. Sales is the most common, but Manual works just as well if you want to test by hand. Each engagement type has its own calculation dropdown.
Before the binding, that dropdown only offered Fixed. With a linearChain or parentChild group bound, two new options appear:
- Upline cascade: credit collaborators above the trigger.
- Downline cascade: credit collaborators below the trigger.
Pick Upline cascade for this walkthrough. The dropdown swaps in a different set of inputs.
If you don’t see Upline or Downline in the dropdown, the bound group is probably flat. Flat groups don’t expose the hasLayer capability that cascade calcs require, so the picker hides them. Read Calc capability matching for the full mechanic, then re-check your group’s structure.
Step 3: Set per-layer points
Fixed asks for a single value. Upline and Downline replace that with five inputs: pointsAtLayer1 through pointsAtLayer5. Each layer is one step away from the triggering collaborator. Layer 1 is directly above (for upline) or directly below (for downline). Layer 5 is the furthest the cascade will reach.
For a three-tier payout, set:
pointsAtLayer1: 100pointsAtLayer2: 50pointsAtLayer3: 25pointsAtLayer4: 0pointsAtLayer5: 0
A zero (or negative) on any layer stops the cascade right there. Layer 4 is zero, so the walk stops after layer 3, even if the chain or tree extends further. Five layers is the hard cap. You can’t extend past it from the UI.
Save the program.
Step 4: Fire a trigger and see the cascade
Now trigger the engagement type you configured. For Sales, place a WooCommerce order that is attributed to one of the collaborators in the group. Attribution is what ties the order to a collaborator, usually their referral link or their coupon code, so check out using that collaborator’s link or coupon. Pick a collaborator who sits deep enough in the chain (or tree) to have real upline above them. For Manual, create a manual engagement on that collaborator directly, with no order needed.
Once the trigger fires, open the program’s engagements list. You’ll see multiple rows appear for that single sale, one per layer that earned a credit. With a chain of five and a sale triggered by the bottom collaborator with per-layer config 100, 50, 25, 0, 0:
- The collaborator one step above the seller gets a row with 100 points.
- The collaborator two steps above gets a row with 50 points.
- The collaborator three steps above gets a row with 25 points.
- Nothing for layer 4 and layer 5. The cascade stopped at the first zero.
- The collaborator who actually triggered the sale gets no row. Cascades never credit the trigger, only the layers above (or below) them.
If anyone in the chain is suspended or deleted, that layer is skipped and pays nothing. The credit is not reassigned, and the cascade does not renumber. Everyone else keeps their own layer and rate. So if the layer-1 person is suspended, layer 1 pays out nothing and the layer-2 person still earns 50, the layer-2 rate, not 100.
Step 5: Watch the obligations
The engagements are only half the picture. When the program’s incentive structure resolves (which happens when the transaction completes), those per-layer point values drive the actual dollar split.
If you’re using Performance-weighted pool (the natural fit for cascades), the pool divides the commission proportionally to each collaborator’s score. Scores of 100, 50, and 25 split the pool 4:2:1. On a $70 commission pool that’s $40 to layer 1, $20 to layer 2, and $10 to layer 3.
Open the obligations list for the program and you’ll see those dollar amounts land on the same three collaborators that earned the engagement rows in the previous step. Same people, same proportions, just now expressed in money rather than points.
If you swap the program over to a different distribution structure (say, top score wins), the layer-1 collaborator takes the whole pool because they have the highest score. The cascade just produces the scores. What happens with them is the distribution structure’s job.
The same flow on a distributor
Distributors work the same way. The Distributors edit screen has the same Group tab on its Collaborators section, the same calc picker on each metric type, the same per-layer inputs when you pick Upline or Downline cascade. The only difference is that you’re configuring a metric type instead of an engagement type, and you’ll trigger a metric instead of a sale.
Bind the group, pick the cascade calc on the metric type, set per-layer points, fire the metric trigger. You’ll see the same multi-row pattern in the distributor’s metric list, one row per credited layer, the triggering collaborator excluded.
What you’ve done
You bound a collaborator group to a program, picked a cascade calculation strategy, configured per-layer points, fired a real trigger, and watched Siren produce a multi-layer payout that flowed all the way through to dollar obligations.
A few places to go next:
- What is a cascade: the concept page, if you want the mental model laid out cleanly now that you’ve seen it work.
- Upline cascade and Downline cascade: per-strategy reference for the exact behavior and edge cases.
- Choosing a calculation strategy: when to pick Fixed vs Upline vs Downline.
- Linear chain and Parent-child: the two structures that unlock cascades, in detail.