Custom fields and the join form

Last updated September 21, 2026

Every club asks something the next one does not: a county association number, a dietary requirement, whether somebody drives to away matches, which coach they would like. Settings → Custom Fields lets you add those questions yourself, in nine kinds — short and long text, number, date, tickbox, dropdown, radio buttons, email and web address — grouped into sections of your own naming.

Tick show on member portal and a field also appears on the public join form ([pvl_join]), so applicants answer it when they apply rather than the secretary chasing it afterwards.

🔗 Questions that only apply sometimes

Most of what makes a form long is questions that only make sense in context. “Which coach?” only matters after “would you like coaching? — yes”. “Name of your previous club” only if they said they had played before. Asked of everybody, those questions clutter the form and get answered wrongly, and the club then has to work out which answers to ignore.

So each field has an only ask this when… rule: pick another field, a comparison, and the answer that triggers it. The comparisons are is, is not, contains, has been answered and has been left blank. The value box follows whatever field you are testing — a dropdown offers that field’s own options, a tickbox offers ticked or not ticked — so you cannot write a rule that looks right and never fires.

Three things follow from a field being hidden, and they are the point of the feature:

It is never required. A form that refuses to submit because of a question it never showed you is the worst kind of bug to be on the wrong end of.
Its answer is cleared. If somebody changes “played before” from yes to no, the previous club they typed goes with it — otherwise the club is left acting on the answer to a question nobody is asking any more.
The rule is checked twice. Once in the browser, so the form reacts as it is filled in, and once on the server when it arrives, because a browser is not where a rule gets enforced.

👥 Questions for some membership types only

Separately, a field can be limited to particular membership types — a parent or guardian for juniors, an employer for corporate members. On the join form the questions change as the applicant picks their type. A field is only asked when both its condition and its type restriction pass.

One deliberate difference in how the two behave when a field is hidden: a condition that no longer holds clears the answer, because the answer has been contradicted. A field hidden only because it does not apply to this membership type keeps its answer, because nothing has contradicted it — it is simply not on this form.

Common questions

Where does the join form live?: Put the [pvl_join] shortcode on a public page. Applications arrive under Members → Applications for the committee to approve, and approving one creates the member’s account and sends the welcome pack. The setup wizard’s Member Pages step can create the page for you.
Can one conditional field depend on another conditional field?: Yes, and it behaves as you would expect: if the field in the middle is hidden it counts as unanswered, so anything depending on it hides too. Keep chains short — two levels is usually the most anyone can follow when filling in a form.
What happens if I delete the field a rule depends on?: The dependent field is hidden rather than guessed at. Open it and either pick a new field to depend on or set it back to “always ask it”.
Can a field depend on itself?: No — it is not offered in the list, and would be refused if it somehow got through. A rule with no way of ever resolving is not a rule.
Does the join form charge pro-rata for someone joining mid-season?: Yes, if you have turned on payment at the point of joining under Settings → Payments. It charges what that membership type’s own rules say a person joining today pays — the pro-rata amount where you have set one, plus any joining fee — rather than a flat annual figure.
Are custom field answers included in a data export?: Yes. They appear alongside the standard fields in the member export and in a GDPR subject access request.