What are Collaborator Groups?

A collaborator group is a named, dynamic membership of collaborators that programs and distributors can bind to as a single unit. Instead of attaching ten individual affiliates to a program one at a time, you create a collaborator group, drop those ten affiliates into it, and tell the program to use the group. Add an eleventh affiliate to the group later and the program picks them up automatically. Remove someone and they stop participating without anyone touching the program itself.

Collaborator groups exist because the alternative, pasting the same list of collaborators onto every program and distributor that should include them, falls apart the moment that list changes. A collaborator group keeps the membership in one place and lets the things that care about it stay pointed at the group, not the people.

How it’s different from a program group

The names sound similar, so it’s worth pinning down the difference up front. A program group bundles programs so that only one of them runs per conversion. It’s a mutual-exclusion mechanism for overlapping reward rules. A collaborator group bundles collaborators so that programs and distributors can bind to the bundle instead of the individuals. It’s a membership mechanism for reusable rosters.

Program groups answer “which program should this conversion pay?” Collaborator groups answer “who participates in this program in the first place?” The two concepts solve different problems and you can use both in the same setup without conflict.

How it works

A collaborator group has a name, a list of members, and a structure. The members are just collaborators, anyone with an active collaborator record can be added. The structure is what shape the group has internally, and Siren ships three of them. A flat group is an unordered bag of members where everyone is a peer, which makes it the default for Plus and the right fit for most simple cases. A linear chain orders members top-to-bottom by a position field so the group carries an explicit sequence, while a parent-child group arranges members into a tree, with each member pointing at a parent collaborator above them.

For most operators the structure is set once when you create the group and never touched again. The reason it matters is that the structure controls how a cascade reads the group when one is running. Flat groups don’t expose layers, so cascade calculations can’t run against them, while linear chain and parent-child groups do. If you’re not using cascades, flat is fine and the structure choice mostly goes away. The page on choosing a collaborator group structure walks through the tradeoffs in detail.

Binding works the same way regardless of structure. A program can bind to a collaborator group, and so can a distributor. Once bound, the program or distributor treats the group’s current membership as its collaborator list. There’s no copy step. The binding is live, and membership changes propagate immediately. Because it is live, a membership change takes effect on every program and distributor bound to the group at once, so removing a collaborator who is shared across several bound programs drops them from all of those at the same moment. Double-check before removing someone who is shared.

When to use one

A collaborator group earns its keep in a few related situations. The clearest is reuse: any time you would otherwise paste the same collaborators onto two or more programs or distributors, the duplication starts to bite, and even three programs that share the same five affiliates feel that pull quickly. The same group also absorbs churn, because as new affiliates join, old ones leave, and top performers move up a tier, you change the roster in one place instead of editing every program. Beyond reuse and churn, a group becomes the foundation for hierarchy, since anything resembling a tiered or override-based payout needs a structured collaborator group for a cascade to walk. And once any of those reasons applies, the group keeps the operator UI simple as a side effect, because a program bound to a 50-member group reads as one binding on the program edit screen rather than 50 individual attachments.

If you have a single program with three hand-picked collaborators and the list never changes, you don’t need a group. Attach the collaborators directly and move on. Collaborator groups earn their keep when there’s reuse, churn, or hierarchy in play.

Lifecycle

Working with a collaborator group looks like this in practice:

1. Create the group. Give it a name, pick a structure, save it. The create a collaborator group tutorial walks through the screens.
2. Add members. Pick collaborators from the list and add them to the group. For linear chains, set each member’s position. For parent-child, set each member’s parent.
3. Bind it. On a program’s edit screen, or on a distributor’s edit screen, point the collaborator-group binding at your group. From that point on, the program or distributor treats the group’s roster as its participant list.
4. Maintain membership. As people join or leave, add and remove them from the group. Bound programs and distributors pick up the change without any further edits.

Before you delete a group, clear any program or distributor binding first. Deleting a bound group does not detach it and does not warn you. The delete goes through, the group and its members are removed, but the binding stays on record pointing at a group that no longer exists, and the next payout cascade on that program or distributor fails closed and credits no one, with no error. So find every program and distributor pointed at the group, re-point or unbind each one, and only then delete.

For developers: A collaborator group resolves through a structure resolver registered against the CollaboratorGroupStructure capability. See the collaborator groups resource reference and the custom structure resolvers extension page for the full API.