Registration systems and data structure
Event registration data dictionary
Your registration form has grown field by field, and nobody can say for sure what each one means or who uses it.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
A registration data dictionary is a single table that defines each field: its plain meaning, allowed values, whether it is required, who owns it, who may see it and what it is used for. Write it before the form is built, and update it whenever a field changes.
It stops three common problems: two people reading the same column differently, fields collected that nobody uses, and exports that reach people who do not need them.
What a dictionary entry must say
Each field gets one row. The row must be readable by a committee member, not only by whoever configured the system.
| Column | What to write | Why it matters |
|---|---|---|
| Field name and label | The label delegates see and the name used in exports. | Exports often use a different name from the form. |
| Plain meaning | One sentence, including what the field does not mean. | Prevents Name meaning badge name for one person and legal name for another. |
| Format and allowed values | Free text, list of options, date, yes/no. Maximum length. | Controls what you can sort, count and reconcile later. |
| Required or optional | And the reason, stated once. | Required fields are the ones delegates may abandon the form over. |
| Purpose | The specific task that needs it: badge, catering count, invoice, programme choice. | A field with no named task is a candidate to remove. See the field minimiser. |
| Field owner | The person who decides whether it stays and how it is corrected. | Someone must answer when a delegate asks to change it. |
| Who may see or export it | Roles, not names. Link to your export permissions. | Most exports need fewer columns than the full list. |
| Keep or delete | Who decides how long the field is kept after the event. | Retention is a question for your data protection contact. |
Separate the identity fields from the planning fields
Group fields by what they are used for. Identity fields (name, organisation, email) tell you who the delegate is. Planning fields (category, session choice, dietary request) tell you what to prepare. Operational fields (status, payment reference, check-in time) are set by the system or the team, never typed by the delegate.
Keeping the groups apart makes it easier to give the caterer only planning fields and the finance team only payment fields.
Sensitive and open-ended fields need extra care
- Dietary and accessibility requests can reveal health or religious information. Collect the least that the caterer or venue needs, and take the wording of the field to your data protection contact.
- Free-text boxes collect more than you asked for. Prefer a short list of options plus one clearly labelled note field.
- Identity numbers, home addresses and dates of birth should not be added unless a named task and a named owner require them.
How to build it in one sitting
- List every field on the current or planned form, plus fields the system adds itself.
- For each one, write the task that needs it. Mark any field with no task for removal.
- Write the plain meaning and allowed values, then agree them with the person who uses the data.
- Name an owner for each group of fields.
- Add the status values your team will use, agreed in your status definitions.
- Send the dictionary to the data protection contact with the list of sensitive fields.
Worked example · Fictional example
A professional association tidies its form before opening registration
Fictional organisation and figures, written to show the level of detail that is useful.
Persatuan Fiktif Juruaudit Dalaman plans a one-day forum. Its draft form has 19 fields. When the secretariat writes the dictionary, 4 fields have no task: job grade, years in profession, home town and a second mobile number.
Two fields are ambiguous. Name is used for the badge by the printer and for the invoice by finance. The secretariat splits it into badge name and invoice name, and makes badge name default to the delegate's name. Dietary request becomes a list of options plus one note, and the caterer is named as the only outside recipient of its aggregate counts.
Use this yourself
Registration data dictionary: one row per field
Copy this block once per field and keep all rows in one sheet.
- Field label and export name:
- Plain meaning (and what it does not mean):
- Group: identity / planning / operational:
- Format and allowed values (maximum length):
- Required or optional, and why:
- Task that needs it:
- Owner (role):
- Roles who may see it:
- Roles who may export it:
- Sensitive? If yes, wording sent to the data protection contact on: (date)
- Keep or delete after the event: question sent to (name) on (date)
Handle it in-house, or bring in help?
Your team can usually handle this when
- The form has fewer than about 20 fields and one person owns it.
- One system holds the data and you control the exports.
- Your team already has a data protection contact to ask.
Outside planning help earns its fee when
- Several teams or suppliers hold copies of the delegate list.
- Fields were added by different committees and nobody can explain them.
- You are moving between registration systems and need the fields mapped one to one.
Need the fields agreed across committee, finance and suppliers?
A conference project lead can run the field review with the secretariat, finance and each supplier, record who owns each field, and hand you a dictionary the whole team uses. Questions about what you may collect and keep stay with your data protection contact.
Questions organisers ask
Is a data dictionary the same as the registration form?
No. The form is what delegates see. The dictionary explains each field behind it, including fields the system fills in and fields that never appear on the form.
Who should own the dictionary?
Usually the secretariat head or the event owner. Each field also has its own owner, such as finance for payment fields.
Do we need one if we use a ticketing platform?
Yes. The platform has its own field names and exports. The dictionary maps what you want to what the platform actually produces. Check the platform's own documentation or support for how it names and exports fields.
Can the dictionary tell us what is allowed under Malaysian privacy law?
No. It records what you collect and why, which is the material your data protection contact needs to review. The legal question belongs to them.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.