Membership & Event Operations Platform

What it does

The platform runs the membership and event operations of a church organisation with 1,397 branches, grouped into 226 zones and 55 districts across more than fifteen countries. It holds the member roll, tracks duties and assignments, and runs registration and logistics for national events. It also reports at every level of the organisational tree and sends the email that goes with all of it.

How it started

In 2010 this was a set of tools for individual events, one tool per event. People kept using them long after the event they were written for, and none of the tools knew anything about the others. The same person could exist several times over, in several places, with no way to reconcile the records.

By 2015 that was no longer workable. A second engineer joined, the code went under version control for the first time, and we merged the separate tools into one system with a single member roll underneath it. Everything built since sits on top of that roll.

Registration for one event overlaps preparation for the next, and the member roll is in use all year round. Every large change has therefore had to happen underneath a running system:

• The backend moved from .NET Framework to .NET Core with no cutover weekend.
• The frontend was rebuilt in Next.js 15 and React 19, 77 pages and 155 components, over about two years. The old frontend stayed up until the new pages replaced it one at a time.
• 77 Entity Framework migrations have run against production data, with no data loss and no downtime.

Authentication and authorisation

Permissions live in the application and are keyed to the user’s verified email address rather than to the identity provider’s subject identifier. Auth0 handles sign-in and nothing else.

We learned this from a failure. When permissions were keyed on the subject identifier, anyone who signed in with a second account arrived as a stranger with no permissions, even though it was the same person with the same email address on a different provider. Keying on the verified email means all of one person’s accounts share a single set of permissions.

Permissions also follow the organisational tree, so a district administrator sees their district and nothing above it. A grant can carry an expiry date, which means someone can be given access for a single convention without anyone having to remember to remove it afterwards.

Audit logs

People ask about membership data years after the fact. Who assigned this person to that duty? When did this branch change districts? The schema answers those questions with audit logs, soft deletes and history tables across membership, duty assignment and registration, so the answer comes from the system rather than from whoever happened to be in the room at the time.

Eleven years of records are traceable this way.