When Conference Data Stops Meaning the Same Thing: Define Every Registration, Author and Attendee Field

A program team asks how many attendees are confirmed. The registration report counts paid orders, the CRM counts people marked active and the check-in report counts arrivals. Each team may have an accurate number, but each number answers a different question.

The problem is not necessarily the software. The teams have not agreed on what “confirmed attendee” means. A conference CRM data dictionary gives registration, program, finance and onsite teams one approved reference before they collect, move or report conference data.

A conference CRM data dictionary is the approved reference for what each field means, how it is formatted, which values are allowed, where it originates, who owns it and how changes are recorded. It prevents teams from treating author, speaker, registrant, attendee and checked in as interchangeable. The team should approve the dictionary before forms, integrations, imports and reports rely on those fields.

A dictionary defines data before systems move it

Conference teams use several documents to manage data, but those documents answer different questions. The dictionary comes first because every later decision depends on a shared definition.

These documents connect, but they cannot replace one another. If a team maps fields or builds reports before it agrees on the definitions, it only moves the disagreement from one place to another. First approve the meaning, format and ownership of each field. Then give those decisions to the people responsible for forms, imports, integrations and reports.

Start with records, roles and relationships

Begin by listing the records the conference uses. Do not start with every screen or form. Start with the facts that the organization needs to understand and manage.

• Person or contact
• Registration or order
• Author and co-author relationship
• Submission or abstract
• Reviewer assignment
• Speaker or presenter role
• Session and schedule placement
• Ticket, payment or invoice status
• Attendance, check-in or session scan
• Consent or communication preference

One person may hold several roles. Author, reviewer, presenter and attendee often describe relationships or activities linked to one contact. They do not necessarily describe four different people.

Consider an illustrative case. A contact submits two abstracts, co-authors a third, registers once, presents one accepted paper and attends four sessions. The dictionary should define each relationship instead of forcing every fact into one status field. That separation also helps the team collect approved registration information without confusing registration, payment and attendance.

Use a separate process to review and merge duplicate contact records. The dictionary defines identity fields and record roles. It should not contain matching or merging instructions.

Give every dictionary row the details people need

A useful row should make sense without opening the software. Give each field enough context for a registration manager, program lead or reporting owner to interpret it in the same way.

This is a working model, not a universal conference schema. Microsoft’s EventRegistration model shows how a platform can document names, descriptions, formats, identifiers, status and version information. InEvent’s field documentation groups information into areas such as attendee details, registration, interaction, feedback and system-generated data. Use these sources as examples of structure, not as definitions that every conference must adopt.

A worked conference field dictionary

The following rows provide an illustrative starting point. Replace the wording, values, owners and approved systems with rules that fit your organization.

A complete dictionary would also record the blank meaning, approved record, sensitivity, retention reference, reporting use and version note for each row. Keeping those details outside this compact example makes the table easier to read, but it does not make them optional.

Define roles and statuses clearly

Words such as attendee, presenter, accepted, paid and checked in often cause the most confusion. Ask the same five questions whenever the team defines a role or status:

1. Which record does the status describe?
2. What action or decision changes it?
3. Can more than one status apply at the same time?
4. Who or what sets the value?
5. Which date and time show when it changed?

These illustrative rows show the difference between a vague label and a usable business definition.

Apply the same discipline to registrant, author, accepted, paid, active and cancelled. For example, “accepted” should state whether it describes a submission, a presenter invitation or a registration. Adapt every definition to the organization’s approved rules.

Control values, formats and blank states

After the team defines a field, it should decide how people will record the value. Use an approved list when consistent reporting matters. Allow free text only when the team genuinely needs an open response.

• Set one format for dates, times and time zones.
• Agree on country, language and organization names.
• Explain whether the order of multiple selections matters.
• Record units, currencies and decimal rules where relevant.
• Define the format of contact, registration and submission identifiers.
• Separate “No” from “Unknown” in yes-or-no fields.
• Record values that the team has retired and name their replacements.
• Check external code lists against institutional and publisher requirements before adopting them.

Most importantly, define every blank. An empty field might mean unknown, not applicable, not yet collected or deliberately withheld. If the dictionary allows one blank to carry several meanings, reports cannot distinguish those situations.

Consider dietary information. A blank might mean the attendee has no stated requirement, has not answered the question or was never asked. Those meanings lead to different operational decisions, so the field definition must make the difference clear.

• Unknown: The team does not know the answer. For example, a legacy contact has no recorded country.
• Not applicable: The field does not apply to the record. For example, a free registration has no payment date.
• Not yet collected: The workflow will request the value later. For example, a presenter has not completed onboarding.
• Withheld: The person chose not to provide the value, such as leaving an optional demographic question unanswered.

The organization may use different labels, but it should document the difference. Do not make staff infer the meaning from the surrounding record.

Name the source, approved record and field owner

Teams often confuse three responsibilities. Separate them in every important dictionary row.

• Source: Where does the value first appear?
• Approved record: Which approved place wins when values conflict?
• Business owner: Who decides what the field means and approves changes?

Consider affiliation. An author enters it during submission, updates it during registration and later asks a staff member to correct it. The team needs a rule about which version to use. The dictionary records that authority rule. A separate integration plan explains how systems exchange the approved value.

The field owner should approve definitions, settle ambiguity, review proposed values, explain changes to affected teams and confirm the effect on reports. The owner does not need to perform every data update. The role exists to keep the meaning stable.

When two systems disagree, the team should not choose whichever value is easiest to reach. It should follow the authority rule recorded for that field. One approved record may govern registration status while another governs payment status. Recording the decision field by field avoids the false assumption that one system must control every fact.

Flag sensitive fields before they spread

The dictionary should flag information that needs privacy, security, legal or accessibility review before teams copy it into forms, exports and reports. Examples include:

• Contact details
• Accommodation or access requirements
• Dietary information that may reveal sensitive facts
• Demographic information
• Payment and tax-related data
• Reviewer identities and conflicts
• Consent and communication preferences
• Attendance and location records

Use labels such as public, internal, restricted and specialist review required only after the organization approves their meaning. Link each field to the relevant privacy, security and retention policy. Do not use the dictionary itself to invent legal classifications or retention periods.

Record changes so old data still makes sense

A definition can change even when the field name stays the same. Record each approved change so teams can understand historical imports and reports.

• Version number and effective date
• Requested change and reason
• Field owner and approver
• Old and new definition or allowed value
• Effect on forms, imports, reports and historical data
• Retirement date and replacement field or value
• Communication sent to affected teams

Suppose “Confirmed” once meant that a person had completed payment. A new invoice workflow later allows the registration team to confirm a person before payment arrives. If the team changes the definition without recording an effective date, a trend report will compare two different meanings as if they were the same.

This short record preserves the historical meaning without asking the team to rewrite old registrations. Label the dates and values as illustrative, then replace them with the organization’s approved decision.

After approval, send the change to the people responsible for forms, imports, integrations and reports. The dictionary records the decision. Those teams decide how to implement it in their own work.

Build and approve the first version

A focused working session can produce the first useful version. Start with one workflow that causes recurring disagreement instead of trying to document every field at once.

1. Select one workflow with recurring confusion.
2. Export or list the fields people currently use.
3. Group them by record and business process.
4. Find duplicate labels and conflicting meanings.
5. Draft definitions, formats, allowed values and blank rules.
6. Name the source, approved record and business owner.
7. Flag sensitive or retained information for specialist review.
8. Test the definitions against three real situations.
9. Approve and version the dictionary.
10. Hand the approved version to form, integration, migration and reporting owners.

Use a difficult case during testing. One person is an author, a reviewer and a paid attendee but has not checked in. If any field produces an unclear answer, revise the definition before approval.

Ask each field owner to approve the rows that belong to that team. Then ask one accountable owner to approve the version as a whole. Record open questions instead of hiding them in vague definitions. The first version does not need to cover every field, but every included row should have a clear meaning and owner. Review the approved dictionary again after any major workflow or reporting change.

Once the meanings are approved, the technical team can map approved fields between systems. That next stage should not change the definitions agreed in the dictionary.

Where Dryfta fits

Dryfta brings contact, registration, abstract, speaker and attendee workflows into one event-management platform. Consistent field definitions help organizers use those connected records without treating every role or status as the same fact.

The dictionary remains the organization’s decision. Dryfta does not replace the team’s responsibility to define business meaning, approve access labels or settle every conflict between external systems. Organizers can use Dryfta Event CRM to manage connected attendee and speaker records after they have agreed on the definitions that matter to their conference.

Discuss your conference data workflow with the Dryfta team and see how the platform supports registration, submissions, speakers and attendees.

Frequently asked questions

What is a conference CRM data dictionary?

It is the approved reference for the fields used across conference records. It explains what each field means, how people should format it, which values they may use, where it first appears, which approved record takes priority and who owns the definition. It can also flag sensitive information, link to retention rules and preserve a history of approved changes.

Is a data dictionary the same as field mapping?

No. The dictionary defines the meaning and permitted form of each field. A field map explains how an approved field corresponds to, or moves between, two systems. Teams should agree on the dictionary first. Otherwise, a technically correct mapping can transfer a value whose meaning differs between registration, CRM, submissions or attendance records.

Who should own the conference data dictionary?

Name one person or group that remains accountable for the dictionary as a whole. Then assign business owners to field groups such as registration, submissions, finance and attendance. Privacy, security, legal and retention specialists should review relevant fields, but they do not need to own the complete document. This structure keeps decisions clear without giving one person responsibility for every conference process.

Which fields should the dictionary include first?

Begin with fields that change operational decisions or appear in several workflows. Common priorities include contact ID, registration status, payment status, author role, presenter approval, submission acceptance, consent and check-in time. Also include any field that teams currently define differently or use in an important report. Expand the dictionary after the first group has clear definitions and owners.

How often should the dictionary be updated?

Update it through a controlled version whenever a definition, workflow, allowed value, approved record or reporting use changes. Record the effective date, reason, owner, approver and effect on historical information. Do not overwrite an old meaning without a record. A change history lets teams interpret earlier imports and reports even after the conference adopts a new process.