Introducing Collaborator Groups and Cascades

A junior partner of yours closes a sale. Good. Now you want the senior partner who recruited, trained, and still backstops that junior to earn a slice of that same sale, automatically, the moment it happens. Not a flat bonus you reconcile by hand at the end of the month. Not a second program you stand up and babysit. The same sale, paying two people, because that’s how the reporting line you actually run is supposed to work.

Until 3.3.0, the honest Siren answer to that was “sort of.” You could approximate it with program groups or a distributor pool, and those are good tools, but they solve a problem that sits next to this one. Neither of them takes one sale and fans it out across a chain of people, one layer at a time. That’s the gap 3.3.0 closes, and it’s the feature I’ve wanted to ship for a long time.

What shipped in 3.3.0

Two new things, and they’re independent of each other.

The first is collaborator groups: a named, reusable roster of collaborators you can bind to a program or a distributor as a single unit. The second is cascades: a payout that walks a structured roster and credits a whole reporting line off a single trigger, one layer at a time.

Both are additive and both are opt-in. If you run a standard affiliate program today, nothing changes and there’s nothing for you to do. You can read the whole release in the 3.3.0 changelog. Everything below is for the people who’ve been trying to model a team, a sales org, or a partner network and kept hitting the edge of what one program could express.

Collaborator groups: stop rebuilding the same roster

If you’ve ever pasted the same thirty affiliates onto a new program for the fourth time, this one’s for you.

A collaborator group is a roster you build once and reuse. You name it, you put collaborators in it, and then you bind it to whatever needs it. The win is maintenance: change the roster in one place and every program and distributor bound to that group updates live. Add a new partner to the group and they’re instantly eligible everywhere the group is used. Remove someone and they’re gone everywhere, at once.

This is the part people conflate, so let me be precise about it. A collaborator group is not a program group. A program group answers the question “when two programs could both pay on this sale, which one fires?” A collaborator group answers a completely different question: “who’s in this thing?” One is about resolving overlap between programs. The other is about membership. You can run both at the same time, and plenty of stores will.

Groups also work as an allow-list. Bind a flat group to a program and you’ve got an invite-only roster where only the people in the group can earn, running right alongside any direct bindings you already have. That alone is enough to run a private partner program or a curated content partner program without hand-managing eligibility on every sale.

That’s the whole Plus-tier story, and it stands completely on its own. You don’t need cascades to get value out of groups. But groups are also what cascades walk, so let’s get into the interesting part.

Cascades: when one sale should pay a chain

The cleanest way to see what a cascade does is the one in the tiered affiliate cascade recipe, so that’s the example I’ll ride for the rest of this post.

Picture a single reporting line, four people deep. At the top is the regional lead, then a team lead under her, then a senior rep, then a junior rep at the bottom. This is a linear chain: a ladder, one person per rung, each reporting to the one above.

Now the junior rep at the bottom closes a sale. With an Upline Cascade configured for three layers, the credit walks up the chain from the person who triggered it. The senior rep one layer up earns the largest slice, the team lead two layers up earns less, and the regional lead three layers up earns less again. The recipe uses 100, 50, and 25 to express that, and we’ll get to why those aren’t dollar figures in a minute.

And the junior rep, the person who actually made the sale? They earn nothing from the cascade. That’s not a bug, that’s the point. A cascade credits the people above (or below) the collaborator who triggered it. The seller’s own commission comes from a separate calculation on the same program, usually a plain Fixed payout. The cascade is purely the override that flows along the line.

The word “layer” trips people up, so it’s worth being exact: a layer is distance from the trigger, not a fixed rank. That’s what lets the same cascade pay correctly no matter who in the chain happens to make the sale. From there, two settings give you the rest of the control you need. A cascade reaches as far as five layers deep, and the moment you set a layer’s value to zero it stops, which is how you say “only pay three deep” even when the chain runs longer than three.

Downline is the same machinery with the direction flipped. Set the strategy to Downline Cascade and the credit walks down from the trigger instead of up. Direction is just a setting. The interesting wrinkle downline is that a single layer can hold more than one person. In a parent-child structure, the layer below a manager might be a whole peer group of reps, and each of them gets that layer’s credit. That’s an org chart instead of a ladder, and the cascade handles it the same way.

If you want the configuration walkthrough, it’s in configure cascade payouts.

Scores, not dollars

I keep writing “100, 50, 25” and not “$100, $50, $25,” and that’s deliberate, because it’s the thing that trips people up.

The per-layer numbers aren’t dollar amounts. They’re weights. On their own they don’t pay anyone anything. They become money when you pair the cascade with a performance-weighted pool, and then the weights decide how that pool gets split.

So the recipe’s 100/50/25 isn’t three fixed dollar figures. It’s a 4:2:1 ratio. Put a $700 pool behind it and the senior rep’s 100 becomes $400, the team lead’s 50 becomes $200, and the regional lead’s 25 becomes $100. Shrink the pool to $70 and the same weights pay out $40, $20, and $10. The ratio holds, and the dollars scale with whatever the pool actually is. Those numbers are this recipe’s example, not a rate card. Pick whatever ratio matches how much weight each layer should carry.

This is why cascades compose with the incentive structures Siren already has instead of replacing them. The cascade decides shape (who gets what proportion), and your pool decides size (how much there is to go around). That separation is also why a team performance bonus, where a monthly pool is split across a team weighted by the lead, falls out of the same machinery.

What this is for, and what it isn’t

I want to be direct about this, because the shape of the feature invites a question I’d rather answer head-on.

A cascade credits a hierarchy you define, and the hierarchies it’s built for are the ordinary ones: a sales org where managers sit over reps, a channel network where a regional manager sits over dealers, a brokerage where team leads sit over agents, a teaching team where a lead instructor’s people share in course revenue. In every one of them the reporting line already exists in the real world. You’re just telling Siren what it is so the override can pay along it.

Nobody gets paid for recruiting anybody. The triggering collaborator is never credited by the cascade for bringing someone in, because the cascade doesn’t credit the trigger at all, in either direction. There’s no enrollment reward, no bounty for signing up the next person down. The override flows along the structure you built, for the work that structure represents: a manager backstopping a rep’s deal, a lead instructor running a teaching team, a regional manager over a dealer’s reported sales. The linear chain is a single reporting line. The parent-child structure is a branching org chart. Both describe a real organization, not a thing you grow by adding rungs underneath you.

If that distinction matters to you, and it should, the design is on your side here. This rewards the structure you already run.

Which tier, and how to start

Collaborator groups land in Plus, along with the flat group structure and group-bound eligibility. That’s the “stop rebuilding the same roster” set, and it’s plenty on its own. The hierarchical structures, the linear chain and parent-child, move up a tier into Pro, and so do the Upline and Downline Cascade payouts for engagements and metrics. Pro is where the worked example in this post lives.

The fastest way to feel it is to build one. Start with the tiered affiliate cascade recipe, which is the 4:2:1 example above, then walk through creating a collaborator group and configuring the cascade payout. If you’d rather start from the concept, what is a cascade is the place.

Cascades weren’t the only thing that rode 3.3.0, either. If you collect leads through forms, the new Ninja Forms pay-per-lead integration shipped in the same release.

I’ve been wanting to give one sale the ability to pay more than one person for years, without turning Siren into the thing affiliate operators are right to be wary of. 3.3.0 is that, and I think the way we drew the line is the best part of it.