Branches vs. Federated Membership: Choosing How Your Organisation Connects
A national body with independently-run member organisations can structure the connection two genuinely different ways. Here's how to tell which one you actually are.
Picture a national association connected to independently-run organisations in a dozen cities. Each one runs its own events, recruits its own volunteers, and answers to its own local board. The head of each one also sits on the national body, paying dues on its behalf and coordinating with the others a few times a year.
Structurally, that's two different problems wearing the same description. Either the national body is the one entity behind every one of them, or each one is its own entity that has simply chosen to belong. YeahApp supports both, and they work in genuinely different ways. Getting the choice right early saves you from restructuring later.
The two shapes
Branches turn one community into a family of them. Create a root community, add a branch for each city or region, and the root's owner runs the whole cluster: one subscription, one connected Stripe account, one member limit shared across everything underneath it.
Federated Membership, which isn't a single feature so much as a pattern, keeps every member organisation as its own separate community. Nothing links them at the database level. The only connection is that an organisation's president, like anyone else, can hold a paid membership in a completely different community: in this case, the national body's.
Which one fits depends on a question that has nothing to do with software: whose legal entity is it today? If the answer is "the national body," branches match that reality. If the answer is "its own, and it always has been," federated membership does.
Branches: one entity, everywhere
Create a branch and it inherits almost everything from the community above it. It runs on the root's subscription — Starter, Pro, or Business — so there's no separate bill to track, and it goes through the same connected Stripe account, so ticket sales, dues, and payouts for every branch land in one place. The member limit isn't per branch, either. It's one number shared by the root and everything beneath it, so a 500-member Pro plan means 500 members total, not 500 in each branch.
The root's owner and admins get authority over every branch automatically, without needing to be added as a member of each one. That matters more than it sounds: the national body can step into any branch's member list, events, or finances the moment something needs attention, rather than waiting on an invitation from a local admin who might be unreachable.
Branches also make it easy for people to move. Someone relocates. Or they simply started in the wrong branch. Either way, they can request a transfer to another branch in the same family, and an admin of the destination approves it. Their old membership closes, the new one opens, and nothing has to be rebuilt from scratch. It's a small thing until the first member asks for it.
The cost of all that is autonomy. A branch can't run its own Stripe account or sit on its own plan, and it can't be deleted or handed to a new owner independently of the root. If the group joining as a branch is used to keeping its own books and answering to its own treasurer, becoming a branch asks it to give that up.
Federated Membership: independence, connected by dues
A member organisation that's already its own legal entity doesn't need to give any of that up. It keeps running as its own YeahApp community, on its own subscription, with its own connected Stripe account for its own payouts. Its volunteers fill out its member roster; its member limit has nothing to do with any other member organisation's.
The link to the national body is ordinary, not special. An organisation's president simply also holds a membership in the national community's membership plan, the same as anyone paying dues would. One person running one community and paying into another isn't a workaround. It's just how YeahApp already works, whether or not the two communities have anything to do with each other.
Two things make this feel deliberate rather than improvised. On the national body's side, member groups (Business plan) let you tag which of your paying members represent a member organisation rather than support it as an individual, so a message meant for organisational representatives doesn't also land in every donor's inbox. On each organisation's side, it's worth going through organisation-account verification individually, not as the national body, but as that organisation's own account. It earns that organisation's community its own Verified badge, and it changes the wording on its public donation page from a disclaimer about being unverified to a shorter, more confident line. That verification only covers the communities the same account owns, though. There's no single action at the national level that verifies every affiliated organisation at once. Each one does it on its own.
What you give up is what branches make free. There's no shared member cap to pool, so smaller organisations often end up paying for their own plan even at modest size. Nor is there any automatic authority: the national body sees only what a member organisation chooses to share with it. And there's no built-in way to move a member from one organisation's community to another. Moving means leaving one and joining the other from the beginning, dues history included.
Which one, in practice
| Branches | Federated Membership | |
|---|---|---|
| Legal and financial structure | One entity behind every branch | Each one is its own entity |
| Billing | One subscription for the whole cluster | Each one buys its own plan |
| Payouts | One connected Stripe account, shared | Each one connects its own |
| Member limit | Shared across the root and every branch | Separate for each one |
| Admin authority | Automatic, root over every branch | None automatic — only what's shared |
| Moving a member between them | Self-serve request, destination admin approves | Not built — join the other from scratch |
| A representative's relationship to the national body | Appointed branch admin | An ordinary paying member |
| Trust badge | Covers the whole cluster at once | Each one verifies on its own |
| Best fit | One organisation running its branches directly | A network of member organisations that already run themselves |
Most of this decision was made before anyone opened YeahApp. If the national body is already the one signing every branch's lease and reconciling its books, branches just mirror that. If each one already banks under its own name, federated membership mirrors that instead. YeahApp doesn't ask you to restructure to fit the software — it asks which structure is already true.
Setting up Federated Membership
Picture the UN and its member states, or a national federation and the independently incorporated regional bodies that belong to it. Neither side runs the other. The only connection is that one holds membership in the other, the same as any member would.
Each member organisation's own setup
This part isn't the umbrella body's to configure. It belongs to the separate community itself, and there's rarely a reason to hand over a checklist unless it's asked for.
What matters conceptually: a member organisation whose leadership rotates, a UN member state changing its ambassador, a regional body electing a new chair every term, is better off owning its YeahApp community through a role account than through whoever happens to hold office this year. A role-based email, one stable human behind it, verified with Stripe as a Company or Non-profit rather than an Individual. The payoff is continuity. Leadership turns over, the role inbox and the Stripe representative get updated, and the community itself never has to change hands. Verify as an Individual instead, tied to one founder's personal address, and the next handover means a full Stripe re-onboarding from zero.
Whoever runs that separate community can get the full walkthrough here: Setting up your YeahApp account — best practices.
What the national body sets up
This part is yours. Create the affiliation-dues membership plan on your own community, the same as any dues plan, then create a member group for the organisations that hold membership through it. Call it Representatives, or Delegates, whatever matches how your governance already talks about itself.
Link the group to the dues plan and its subscribers populate automatically, or assign representatives by hand if "who pays" and "who holds a governance vote" aren't quite the same list. Either way, the plan link only backfills once. Anyone who joins after you save it, or whose dues lapse, doesn't move in or out on their own, so revisit the link occasionally or handle changes by hand. Once the group exists, use it to target a governance-only event or post, a congress, a delegate ballot, so it reaches representatives without landing in every ordinary supporter's feed too.
See Member groups and access control and Creating a membership plan on YeahApp for the mechanics.
Verifying each member organisation
A role account already sits on a real domain, so it qualifies for organisation-account verification: its own Verified badge, better wording on its own donation page. Same principle as its account setup, each member organisation does this for itself, once. There's no umbrella-level action that covers the whole network at once. See Verification.
If branches suit your organisation better instead, the setup lives at Sub-communities and branches.
If you're weighing this for your own organisation, take a look at the platform overview, and when you're ready, book a demo with us and we'll work through the structure with you.