Invitation and enrolment
Nobody joins by finding a link
Getting forty young people signed up in a hall on a Tuesday and keeping strangers out are two goals that pull against each other. This is where the product puts the line, and what it refuses to trade for convenience.
- 0
- ways to sign up without an invitation
- 1
- people who must approve a new member: at least one
- 1
- member per redemption, however many times a code is scanned
- 0
- settings on an issued code that can be widened afterwards
- Invite-only — there is no public sign-up form to find
- A named person approves every new member before they are in
- A code is frozen when it is issued and cannot be widened later
Two gates
Both of them are a person, on purpose
Automated joining is where most platforms leak. Here the two checkpoints are human, and neither can be skipped by knowing a URL.
Somebody invites you
An account exists because a person with authority in the organization created a way in for you. There is no open registration page — not hidden, not rate-limited, not there.
Somebody approves you
A new member sits in a pending state until an administrator admits them. Being invited and being in are two different things, and the gap between them is deliberate.
And there is no route around either
Enrolment through a code lands in the same place: it produces somebody waiting for approval, not somebody already inside. Where a jurisdiction requires that approval step, an organization cannot switch it off for itself.
The approval requirement is bounded by your jurisdiction. Your organization may insist on more; it cannot decide to need less.
What a code can do
A code is a narrow thing, and it gets narrower, never wider
The point of handing a volunteer a code is that they can admit people without being able to admit anybody.
- One role, fixed at issue
- A code admits people as one kind of member, decided when it is minted. There is no code that can produce a leader by accident, and none that can be edited into producing one.
- A maximum number of people
- Once that many have joined through it, it admits nobody else. The cap is checked as part of the redemption itself, not by a screen that could be bypassed.
- An expiry, and a revocation
- A code stops working at a time chosen up front, and can be killed immediately before that. A revoked code stays revoked and an expired one stays expired — neither state has an undo.
- And none of it can be widened
- An issued code cannot be given a larger cap, a later expiry, or a different role. The database refuses the change, which is what makes a code safe to hand to somebody: they cannot make it more than the person who issued it intended.
- One redemption, one member
- A code scanned twice by the same person produces one member, not two. The claim behind a scan is single-use even where the code is not, so a double-tap on a phone in a noisy hall is not a second account.
A young person joining this way must have a date of birth recorded. A redemption that would create a young person without one is refused outright — because an unknown age is what blocks participation, and a route that could skip it would quietly become the route everybody used.
The code on the wall
A printed QR code is a door that never closes
This is the trade the module exists to make, and the place convenience loses.
Printed, it is permanent
A code on a poster can be photographed, forwarded, and used by somebody who has never been in the building — next week, next term, by anybody who walked past. It looks like a small convenience and it is a standing invitation.
So the default code rotates
The code on screen changes on a short cycle, and a picture of it stops working. Somebody has to be in the room while enrolment is open, which is the same requirement a paper sign-up sheet has always had.
And without its key, nothing issues
A rotating code needs a signing key on the server. Where that is missing, issuing fails rather than quietly falling back to a static code. The design will not downgrade to the permanent door because the temporary one was unavailable.
A static code still exists for the cases that genuinely need one, bounded by what your jurisdiction permits. It is a decision somebody makes, with their name on it, rather than what you get by not thinking about it.
What you decide, and what you cannot
An organization can be stricter than its floor. Never looser
The same rule runs through every safety setting in this product, and enrolment is where it is easiest to see.
Yours to set
Which kinds of code you use, how long they last, how many people they admit, whether a guardian’s contact details are required, and what a person is asked for as they join — five tabs of settings, each saved explicitly with a reason recorded.
Not yours to set
Whether QR enrolment is available to your organization at all, whether the approval step can be removed, and the ceilings on lifetime and redemption count. Those sit above you, because an organization under pressure to make joining easier is exactly who would move them.
And the floor holds against everybody
The refusal comes from the database, so it holds whether the request came from a settings screen, an API route, or a script somebody wrote in a hurry. There is no privileged path that skips it.
Every change to these settings is recorded with the person who made it and the reason they gave. Enrolment is how strangers would get in, so who widened it and why is not a detail.
In short
What to tell your board
Three sentences, all of them checkable.
- There is no open signup: somebody invites you and somebody approves you, and enrolment by code lands in the same pending state as any other route.
- A code is fixed at the moment it is issued — role, cap and expiry cannot be widened afterwards, and one redemption produces one member.
- Your organization sets its own enrolment rules within ceilings it cannot move, and every change is recorded with a name and a reason.