Skip to main content
The registration form decides what a new person fills in before they have an account. Orgo gives you one General Registration Form at /register, plus an optional form per user type at /join/<slug>. Built for any organization that lets people sign up themselves, and for organizations that need to ask different questions of different kinds of member. Replaces a website form plus a spreadsheet plus manual account creation. Self-registration is one of four ways somebody gets an account. To create one yourself, invite a specific person, or import a spreadsheet, see Adding Members. Registration form builder: System Fields and Custom Fields tabs, ordered form fields with Required checkboxes, and the Form Settings card

​
Where it lives

Settings → Users & Profiles → Registration Form. Requires ADMIN_TENANT. The entry appears only when Enable Registration Form is on (Settings → Users & Profiles → Configuration → Registration & Membership). While it is off, self-registration is refused with “Registration is not possible.” and the Register link disappears from the login page. Invitation links are the exception: a valid one opens the form as normal, so you can close the door to the public and still admit the people you invite. Registration Forms page showing a table of forms with slug, status, URL and Iframe copy buttons and Configure actions, and the Floating and Side Panel layout choices below it The table lists the General Registration Form first (tagged Default, always active), then one row per user type showing Active, Inactive, or Not configured. URL and Iframe copy buttons appear once the type has a slug; without one the row reads “Set slug first”.

​
Registration page layout

The side image is the login background image set in Branding. Phones and iframe embeds always render the centered layout regardless of this setting.

​
Building a form

Two panels: Available Fields on the left with a System Fields and a Custom Fields tab, Form Fields on the right. Click or drag a field to add it, drag the handle to reorder, tick Required, and use the X to remove it. Email is permanent: always in the form, always required, never removable or optional, and the login identifier.

​
System fields

These are the default labels. Rename vocabulary in Labels and both the builder and the public form show your wording, from the same catalogue.
Signal and Bluesky appear in the builder’s field list but are not rendered by either public registration page. Adding them has no effect. Collect those handles with a custom field instead.
Some older forms contain fields the builder no longer offers, such as a members-map location pin or a personal identification number. They keep working on /register if they were already enabled, but you cannot add them to a new form. Use a custom field for identification numbers, which also lets you encrypt the value.

​
Custom fields

Every profile custom field is on the Custom Fields tab and can sit anywhere in the order, including between system fields. Two exclusions: file-upload custom fields cannot be used on a registration form, and admin-only custom fields never reach the public page.

​
Form settings

Registration form builder for a single user type, with the Active switch and the Copy URL and Iframe buttons in the header, and the Title, intro texts and Default Membership Fee Price selector in Form Settings Consent checkboxes are added automatically and are required when the matching link is filled in on your organisation profile: GDPR policy, terms of service, and internal rules.

​
Publishing and embedding

Set the slug on the user type itself (Roles & User types → edit the type → URL Slug). Use the Copy URL and Iframe buttons to grab either address.
iframe=1 strips the logo and outer chrome. workspace=<your-slug> names the organization, which matters when you embed on your own domain. lang= forces the interface language: bg, cs, de, en, es, et, fr, it, lt, nl, pr, ro, sk, ua.

​
What happens after someone submits

1

Spam checks

A hidden field must stay empty and the form must take at least three seconds to fill in. Failing either returns “Invalid submission detected”.
2

Account created, email unverified

No password is asked for. Orgo generates one and requires the member to set their own at first login. A six digit code is emailed, valid for five minutes.
3

Status resolved on verification

In this order: eligible for the waitlist becomes Waiting list with a queue position; a referral program requiring referrals becomes Awaiting referral with a personal referral link; Manual Approval on becomes Unapproved; otherwise Active.
4

Notifications go out

Organization admins and the member’s chapter admins are emailed about the new registration. At Active, the welcome message goes out if Send Welcome Message is on.
5

Member continues

An Active member is signed in immediately. Anything else lands on a status screen explaining what happens next.
Side panel registration page: photo left, form right with email, name, phone, date of birth, gender, town, chapter and two custom fields

​
Settings that change registration

Found under Settings → Users & Profiles → Configuration.
The registration form has no age gate. Birthday is collected as data only. The minimum-age value is used only when a parent registers a child from inside the app, where a child below the threshold is flagged as underage on their waitlist entry, and the parent’s action is recorded as the consent. That value is not editable in the settings screens today.

​
Troubleshooting

Enable Registration Form is off. Turn it on to reopen self-registration, or leave it off and invite the people you want: a valid invitation link opens the same page and is not refused.
The user type has no URL Slug. Open Roles & User types, edit the type, and set one. Orgo refuses to save a user type registration form while the type has no slug.
That email already has an account in this organization. The form offers a Sign in here link unless that account is inactive, suspended, excluded, or deleted. Emails are per organization, so one address can belong to several.
Correct: the form applies only to new sign-ups. To collect something from existing members, use the profile form instead.
Default User Type After Registration is applied last and wins. It is applied after the type the applicant picked in the User Types field, after the type implied by a /join/<slug> form, and after the type an administrator chose while creating a member by hand. Whatever any of those said, the finished profile carries the default.The clue that this is what happened: the member still holds the role for the type they signed up under, visible on their Roles tab, while the User type on their profile shows the default. The role was granted at sign-up and never touched.Clear the setting if you use per-type forms or let applicants pick their own type. A default only makes sense when there is exactly one answer for everyone, which is precisely the case where the form does not ask.
Required on a registration form is enforced by the browser. That is enough for someone filling the form on your registration page, and it is not enforced anywhere else, so an account created by any other route arrives without those answers:
  • A member an administrator creates with Register member from the directory
  • Anyone loaded through Import
  • A child registered by their parent from inside the app
None of these pass through the form, so none of them are asked. People arriving through an invitation link are the exception: they do fill in this form, so their required fields are collected normally.If a field must genuinely be present on every profile, put it on the profile form and mark it required there: that one is re-checked on every visit and members are redirected until it is filled in.A separate cause for the public form specifically: custom fields set to User or Admin visibility render on the page and are then discarded, whether or not they are marked required. Only Public custom fields survive registration. See Custom Fields.
Search covers the settings catalogue rather than the page you land on, and a few entries in the catalogue are for controls that are not currently built into the Configuration screen. Minimum Registration Age and Children Auth Restriction Age are the two you will meet from this page: both are findable in search, both take you to Users & Profiles → Configuration, and neither has a control there to scroll to. Nothing is broken and nothing is hidden by your permissions.For an age limit on the public form, there is nothing to configure: the form has no age gate at all, as noted above. Collect the birthday and review applications with Manual Approval, or gate joining behind Adhesion.