October 22, 2026 | 11 min read
Short answers to the questions organizers ask most often about building Eventact registration forms. Each answer links to the guide that covers the topic in full. For how forms, field levels, and expressions fit together, start with Eventact Primer: Forms.
Use the + Add Common menu at the top of the form editor. It adds common fields and pages already linked to the correct data field - name, email, organization, job title, country, gender, birth date, the Promo Code field - as well as a ticket select page, a payment page, a networking profile page, and an invoice details page. An option appears only when that field isn't on the form yet, and the field is placed in a standard order on the personal details page. Save the form first, because unsaved changes are lost.
Not when the form uses the standard login - the registrant's email is already captured at the login step, so a separate Email field asks for it twice. If you turn on Skip Login, the login step is removed and the form needs its own Email field; check that it is there after you save. Keep in mind that Skip Login doesn't link the submission to an existing contact or reuse their earlier data. See Identification of Registrants and Participants.
Usually not. Returning registrants sign in with a one-time code (OTP) sent by email or SMS, so a password
isn't needed - and a password field in the form also shows up in the Summary field on the summary page and
in confirmation messages. If you do use one, the minimum length is at least 5 characters, the maximum is
100, and the characters ' " \ < > are not allowed. See
Login & Authentication.
Use back-office fields. Place the fields on an office page - a hidden page of the form that only back office staff can see. Admins can then view and edit the values for each registrant, show them as report columns, and export them to Excel. Eventact usually creates an office page for you; if it's missing, add a new page (for example after the thank-you page) and use it as the office page.
As little as possible. A heavy first page drives registrants away, and a required photo upload there is especially problematic on phones. Move photo and file uploads and secondary questions to a later page, and ask registrants to keep uploaded files to about 500KB. Leave out fields you don't need, such as a zip code, a full address, or an ID number without a clear reason.
Yes. Add a redirect script to the header or footer of the registration completion page, entered in code
mode so the editor doesn't alter it. A delayed redirect lets registrants see the completion message first,
for example setTimeout(function(){ window.location.href = 'https://example.com/thank-you/'; }, 3000);
inside a <script> tag, where 3000 means 3 seconds.
Company fields are shared by all projects, and their data is synced across events - for example name, email, and job title. Project fields are defined in one project, and their data is unique to it. Master fields share one definition across projects, while their values vary per event. Because a Company field is shared, renaming it changes it in every event and form that uses it - create a dedicated field for event-specific needs instead. See Eventact Primer: Field Levels.
Prefer the standard Organization field, which + Add Common adds already linked. If a custom field is already in use, open its settings and, in the Data section, set the data group to Primary and the data field to Organization. Integrations such as a membership database sync write the workplace into Organization, so an unlinked custom field misses that data.
Use the Country field when you only need the country. Eventact takes a person's country from the Country field if the form has one, and otherwise from the address - and a later address change may not update it. Country matters: it is shown as a flag in the back office and can affect taxes. Consider labeling the field "Country or Region" - for example, Taiwan is listed as Chinese Taipei, the name used at international events.
No. A radio field allows one selection, and the maximum-selections setting applies only to checkbox list fields. To let registrants pick several options, open the saved radio field's settings and, under Change field type, click Change to Checkbox list.
Up to 26 - after that the editor shows "Cannot add more items". A menu (dropdown) field has no such limit. For a long multi-select list, such as companies a registrant wants to meet, split it into several checkbox fields. For profile questions you reuse at every event, such as job role or organization type, a Company field with one value list lets you filter your whole database across events.
Add an Agreement field with the consent text and links, and make it required - registrants must tick it to continue. Link a PDF from your own server, or upload it to Eventact with a simple file name of English letters and digits only (no spaces, parentheses, or hyphens). If you leave the field's link text empty, "View agreement" is shown. There is no draw-to-sign signature field; documents that must be signed can be signed by the registrant and uploaded through a file field.
The Flight order field, in the form editor's "From the pricelist" section, sells a flight item from the pricelist. The Flight Details field, under "More fields", only collects arrival and departure information. See The Order Fields.
Yes, with Let the user choose dates, but it is only safe on a Hotel order field, which adds Earliest check-in and Latest check-out to keep bookings inside the contracted period. On a Ticket, Activity, or Transportation field the registrant can pick any dates, so use the event dates, fixed dates, pricelist dates, or another order field's dates instead - for example Use accommodation check-in for an airport transfer. See Order Dates: Where a Field Gets Its Calendar Dates.
Yes. Click the form's Share link button and, in the Share registration link dialog, tick Pre-select a ticket, accommodation or other item, then choose the field and the item - one link per item. The item enters the order as if the registrant chose it. If the order step is visible, registrants can change the selection; dates aren't set through the link, so it suits fixed-date packages. See Getting the Registration Link.
Yes. Take the URL from the Share registration link dialog and append &d=[Field ID],[Value].
The Field ID is in the Data section of the field's properties. For dropdowns and radio buttons pass the
option's internal value, and for checkboxes pass 1 or 0. Test the link in a private window before you publish
it. See How to Set Up a Pre-Filled Registration URL.
Add a condition to the page. For example, ask "Do you have a certificate?" on page 1, put a required file upload on page 2, and show page 2 only to those who answered yes - everyone else skips it. Base conditions on structured fields (yes/no, radio, or menu fields), not on free text, which registrants word in too many ways. On order fields you can also use a visible rule, same-page show/hide, and a validation rule. See Smart Eventact Forms Logic with Expressions.
Add a visibility rule with an expression to the form. isregisteredtoform({Contact.ContactID}, FormID)
is true when the person registered through that form, in this event or another event under the same account.
israpprovedinform works the same way but is true only when that registration has Approved status.
See isregisteredtoform and
israpprovedinform.
Add a condition to the abstract form. isregistered({Contact.ContactID}) checks registration to the
same event, isregisteredtoevent({Contact.ContactID}, EventID) to a specific event, and
isregisteredtoform to a specific form. To check the opposite direction - that a person has
submitted abstracts - use hasabstracts({Contact.ContactID}, EventID), and pass it the event ID, not the
abstract form ID, or the condition fails. You can customize the
message shown to people who don't meet the condition. See
isregisteredtoevent.
For a closed event, turn off Allow New Contacts so only preloaded contacts can pass the login.
To check against a list by ID number instead, add a "not eligible" page as step 2 with a generic message, show
it with isregisteredtoformbypersonidtxt (negated) against the invitee form, and set the page
behavior to End and Cancel, which ends the registration with Canceled status. Don't say the
check is by ID number, so the form can't be used to probe the list. See
isregisteredtoformbypersonidtxt.
Use isnotpaxmember({Contact.ContactID}), which is true when the registrant hasn't already been
selected as an accompanying person by another registrant. Put it in the condition of the form or the step that
should be closed to accompanying persons. See
isnotpaxmember.
Not by IP address - IP and country restrictions apply only to back office access. Restrict by the Country
field instead: add a condition on a registration step so registrants whose country is not the one you want
cannot continue. In expressions, compare {Contact.CountryISO}, the two-letter code, which doesn't
depend on the form's language. See Expressions with Countries.
Yes, with no custom development. islmccountry({Contact.CountryISO}) is true when the registrant's
country is classified as a low-income or lower-middle-income country. For finer control,
getcountryincomeclass returns the income class (1 low-income to 4 high-income). Put the condition
on a free ticket or a free price plan, and use the same condition for a different confirmation message. See
islmccountry.
Yes, if the code is entered in a standalone Promo Code field on the first page - conditions can then test
{Registration.Promo code}. A code entered inside an order field can't be used in a condition, and
neither can the order total. Often the simpler route is a ticket that only registrants with a promotion code
can see. See Restricting Who Can Select the Ticket.
Making the checkboxes required works, but registrants see the standard required-fields message. For your own text, add a Special Page Validation rule in the page's Special Rules that checks all the boxes are ticked, and enter the text in Message if rule is false. Alternatively, leave them optional and use conditions on the next page to show either the next step or a "not eligible" page.
English plus Albanian, Arabic, Chinese, French, German, Greek, Hebrew, Italian, Japanese, Portuguese, Romanian, Russian, Slovenian, and Spanish. Buttons and system messages are translated, dates and currencies are localized, and right-to-left (RTL) languages switch layout. One form can be multilingual - your own field labels and texts must be entered in each language.
Yes. Go to Design > Colors and Fonts, choose the font for text and a separate font for
titles (leave it empty to use the same font), and click Save. You can enter a Google Font with its weight,
for example Raleway:700. See Branding Guidelines: Fonts.
About 1200 x 250 px (a 4.8 ratio), PNG or JPG under 500KB, plus a 600 x 125 px version for small screens. The banner stretches to the full width of the form box, so a much narrower image looks blurry. See Branding Guidelines: Images.
Yes, with custom CSS. Go to Design > Custom HTML and paste your rules - for example to
round the buttons of one form with #eaForm-55555 #form-btns .btn, where 55555 is the form ID.
Changes may take a few minutes to appear. See
Adding Rules in the Back Office.
Two fields are mapped to the same data field, so when the form loads the contact's existing data, the email value lands in the phone field. Find the recently added field that shares the data field and map it to the correct one.
Check the registrant's history, and check whether the form has two fields on the same data field - duplicate fields can overwrite or clear each other's values.
It's a Company field, and someone renamed it for their own event - the change applies to every registration and abstract form that uses it. Restore the name, create a dedicated field for the event-specific need, and check in each affected event which data the field was meant to hold.
By default, the country and the mobile phone prefix follow the registrant's IP address, so registrants abroad or on a VPN may see another country. If everyone sees the same one, check that the field wasn't given that country as a default value. If you don't want a prefix at all, use a mobile phone field without a country prefix.
Check the imported contacts: two contacts with the same ID number, one with a leading 0 and one without, are
treated as two people. Normalize ID numbers before importing so each person has one contact, and use
isregisteredtoformbypersonidtxt, which keeps leading zeros, for ID checks.
Still stuck? Contact Eventact Support. Read more about Eventact Event Registration