Multiple organizations on one platform: every committee in its own space

When a single registration system serves just one organizer, everything looks simple. But the moment a second committee, a third federation, and a series of partner events appear, a question follows: how do you keep everyone on one multi-organization platform without mixing their data, competitions, and participants into one shared mess? We solved this at the architecture level. scoreio is now built from the ground up for many independent organizers: every committee gets its own space, its own competitions, and its own view of the data — all on one unified platform.

How it used to be

The registration system was originally built around a single "owner." One organizer, one competition database, one list of teams, one logic. As long as there's a single client, that works. But the reality of the sport is different: one platform serves many committees, federations, and clubs at once, all running their own events and none of whom should see the others'.

Without separation, this became a constant source of risk. Competitions from different organizers ended up in one shared list. An administrator from one committee could, in theory, stumble onto another's events. Every attempt to seat a second organizer next to the first required either a separate copy of the system or manual restrictions that are easy to bypass and hard to maintain. Scaling hurt: each new organizer was a project, not a setting.

A separate copy of the system per organizer is the worst solution that at first looks like the simplest. You end up with not one platform but five, ten, twenty nearly identical installations. Each has to be updated separately, fixed separately, maintained separately. Find a bug, and you have to fix it in every copy by hand. Ship a new feature, and you roll it out across all installations one by one, and they inevitably drift apart in versions. What was meant as "quickly seat a second organizer" turns into a zoo that gets more expensive with every new participant.

The alternative — manual restrictions over a shared database — looks cheaper but is more dangerous. As long as all competitions physically sit in one common list, the boundary between organizers rests only on the discipline and attentiveness of administrators. One mistake, one wrong filter, one forgotten condition is enough — and a person sees, or worse, edits someone else's event. Such boundaries can't be guaranteed: they exist right up until the first lapse of attention.

What changed

We introduced the concept of an organization type and real separation between organizers into the platform. At the data level, an organization gained a marker for its type, and among organizations some are now "primary" — the ones that own their own space and their own competitions. This turned scoreio from a system "for one" into a platform "for many."

Organization types

Every organization now has a type. This isn't cosmetic — it's how the platform understands what it's dealing with: a standalone committee with its own space, or a structure inside one. The type determines which competitions belong to the organization, what it sees, and what it manages. Thanks to this, the same platform correctly serves both a large federation and a small club running a couple of events a year.

Primary organizations and their spaces

Among organizations, "primary" ones are singled out as owners of their own space. Each space is a separate circuit: its own competitions, its own registrations, its own administrative picture. The organizer works as if the platform existed for them alone, never overlapping with neighbors. Physically, everyone lives on one system that we develop and update centrally.

Data separation

The key consequence: the data is separated. One committee's competitions don't mix with another's. Each organizer sees its own list of events and works within its own boundaries. This removes a whole class of errors: you can't accidentally open, edit, or delete someone else's competition, because it simply doesn't belong to your space.

Importantly, this separation works not as a filter that can be switched off by accident, but as a property of the platform's structure itself. A competition belongs to a specific space — and outside it, it simply doesn't exist for other organizers. So order rests not on administrators' discipline but on the architecture: even if someone makes a mistake, they stay within their own circuit and can't reach others' data. That's fundamentally more reliable than manual restrictions over a shared database.

One center of development for everyone

Even though organizers are separated, the platform stays unified. We develop and update it centrally: a new feature appears for everyone at once, a fix reaches everyone simultaneously, and no one has to "catch up" on a version. That's the main advantage of the "many spaces on one platform" model over the "many copies" model: separation where it's about data, and unity where it's about code and updates.

What this gives you

• One platform, many organizers. No separate copies of the system per committee. Everyone works on a single solution that we develop on one front.
• Clean separation. Your competitions, registrations, and data are yours alone. Other events never appear in your list and aren't accessible to your administrators.
• Fast onboarding for a new organizer. Adding another committee is configuring a space, not a months-long technical project.
• Lower risk of mistakes. Touching someone else's competition by accident is impossible: the space boundaries are set at the platform level.
• Managed growth. However many organizers appear, each stays in its own circuit, and the platform keeps working as a single whole.

Scenarios where this solves the problem

A federation with several regional committees. A central federation and its regional committees run different events. Each regional committee gets its own space and sees only its own events — yet all of them work by unified rules on one platform. The center keeps control, and the regions don't get in each other's way.

A provider serving different clients. You're a company that launches registration for different federations and organizers at once. Before, you'd have to spin up a separate system per client. Now each client is a separate space on one platform: the data is separated, while updates and support are shared — no need to maintain a dozen scattered installations.

A partner event series. Several organizers agreed on a series of stages, but each owns its own block. Each runs its own competitions in its own space, without overlapping partners on data, while everyone stays on one familiar platform.

Handing an event to another committee. Sometimes an event "moves" from one organizer to another — the person in charge changed, a region handed the hosting to the center. When each organizer has its own clear space, it's obvious who owns the event and in whose circuit it lives. There's no ambiguity of "whose competition is this," and no risk that after the handover access is lost — or, conversely, that the wrong people can see it.

Frequently asked questions

Can one organizer see another's competitions? No. The data is separated: each organizer works in its own space and sees only its own events and registrations. Other competitions don't appear in its list.

Do we need a separate copy of the platform per committee? No. That's the whole point: all organizers live on one platform but in different spaces. Updates and support are shared by everyone.

How is an organization type different from a simple role? The type defines the organization's place in the platform's structure — whether it's a standalone space or a subordinate structure inside one. This affects which competitions and data the organization owns and manages.

How many organizations can be connected? The platform is designed from the start for many independent organizers. Adding a new one is configuring its space, not a separate project.

Is this suitable for a small club, not just a big federation? Yes. The same mechanism serves a large federation and a small club with a couple of events a year equally well — each works within its own boundaries.

How to start

Launching a new organizer on scoreio means creating its space and tuning it to its competitions. From there, the committee works as if the platform existed for it alone: running its events, accepting registrations, seeing its data — never overlapping with other organizers. And you get predictable growth without a zoo of separate installations.

Separating organizations is the foundation that makes the rest easy to build: for example, a consolidated competition budget from fees is calculated within the boundaries of your space, and white label branding lets every organizer work under its own name.

Planning to onboard several committees? Request a demo or a pilot launch of scoreio — we'll show how organization spaces are separated and set up a test circuit for your structure.