Subnations, Shared Tags, and the “one nation” approach

Often, when working with larger, multi-site organizations, the question arises of how best to manage multiple chapters / websites in NationBuilder. Often, these clients have already broached the topic with a NationBuilder Organizer and have (understandably) been pointed towards the product’s “subnations” feature. But subnations are not right for every customer, and in many cases can actually make it more difficult — not less — for a large organization to get real value out of NationBuilder. For those clients, I often recommend an alternative set of approaches: shared tags, or a single nation, multiple websites, and a thoughtful set of permission sets.

So what’s the difference, and why would you use one over the other? Lets dig in.


NationBuilder bills its subnations feature as “ the best way to grow medium and large organizing efforts ” — and they are, if each of your local chapters is fundamentally an independent organization. With subnations, each of your local chapters or affiliates will have it’s own, distinct NationBuilder database and website, while still allowing you to push some data “up” to the parent organization. It’s a great way to keep each chapter or affiliate connected, while allowing a wide degree of independence and local control.

If your goal is real time data and transparency, however, subnations are not likely your best option. In a subnations setup, data is only shared “up” (from the subnations to the parents) and never “down” (from the parent to the subnations). That means that any data you collect, update, or append within the parent nation won’t automatically be made available to the subnations. It’s a one-way street.

And if the same person signs up on the sites of two subnations, there’d be no way for them to cross reference those activities between the two nations. They’re siloed from one another — operating in a vacuum.

Instead of subnations, “shared tags”

A less well understood, but totally viable alternative to subnations is NationBuilder’s “ shared tags ” feature. Much like with subnations, shared tags allow customers to sync people data between nations. But while subnations pushes data “up” from the subnation(s) to the parent nation, shared tags can sync between any number of nations.

Instead of a hierarchical filtering up of data from affiliates to a parent, you can instead build a web of nations that all provide mutually beneficial data to one another. And the kicker is that — unlike subnations — nations sharing tags don’t need to be formally linked together like subnations do: they can share the data on an ad hoc basis, forming short term relationships or sharing only limited data around campaigns, etc.

Sounds great right? It is. But it’s got drawbacks, as well. Like with subnations, the “shared tags” approach requires each chapter of affiliate to have its own, stand-alone website. Moreover, like with subnations, “shared tags” don’t transfer any activity history (what actions have they taken, have they been contacted, what donations have they made, etc.). This makes it difficult to maintain a complete, 360 degree view of the organization’s relationship with individual supporters — particularly those supporters who regularly interact with multiple chapters.

The “one nation” approach

At first, it seems counterintuitive: multiple local chapters all working in the same nation? Won’t chaos ensue? But the answer is — with a bit of training and front-end planning — “probably not.”

In the past few months, I’ve launched two client projects that followed this model: the Young Professionals in Foreign Policy (YPFP) and the Convention of States. In both cases, they had dozens (or hundreds) of Control Panel users spread across many local chapters/offices, but subnations didn’t make sense because of the lack of real-time activity history. So we went in another direction, and made a single website for the whole organization and managing the database complexity with point people, permission sets, and follow ups.

The results have been outstanding.

In the case of YPFP, they have a single global site that showcases their eight global locations and a distinct blog, events calendar, and set of membership options for each. But under the hood, their staff has a single people database with realtime, accurate data on each of their members around the world. Their nation is now the single point of truth about their membership.

In Convention of States’ case, they’re running a national organizing effort with (currently) hundreds of Control Panel users across the United States. They could have made a subnation for each site, and shared data between them, but they would have lost the benefit of the real-time data of how their supporters were engaging online (which means the loss of hundreds or thousands of activities / data points each day). Instead, they’re running following the snowflake organizing model, with their database partitioned amoung the various states based on NationBuilder’s point people feature, and their team recently described the real-time national data as “game changing.”

So what should I do?

There’s no one-size-fits-all answer to this challenge. Subnations work fantastically for a lot of NationBuilder customers. Shared Tags are incredibly valuable for coalition building and data sharing between allied organizations. And using a single, large nation can prove incredibly value if it’s done effectively. But they all have tradeoffs, as well.

The point here is not to tell you how to do it, but to convey that there are many options, and that if you’re not sure which one is right for you the best thing to do is talk it through with your Organizer, your Expert, or both.

Share this post