Event RegistrationCopy Anchor Link

OverviewCopy Anchor Link

Event registration lets you attach one or more registration forms to a calendar event, publish them to your public website, and collect and manage the responses -- and any payments -- from your dashboard. A form can be one of three things: a data-collection form, a signup list where people claim items, or a board of time slots people sign up for.

These are registration forms attached to a calendar event. They are a different thing from the general-purpose Forms page template described in Page Templates, which is for contact and inquiry forms that aren't tied to an event.

Where to Find RegistrationCopy Anchor Link

• From a calendar event -- open the event in your group's dashboard calendar and turn on Enable Forms. Forms for that event live at /dashboard/[group]/calendar/[eventId]/registration.
• From the group dashboard -- the Registrations tile (shown to anyone who can manage the group's events) shows every event in that group that has a registration form. This is the fastest way to find an event you set up earlier.
• All responses for one event -- the View all responses button on an event's Forms page.

Turning On Forms for an EventCopy Anchor Link

Registration always starts on the calendar event itself.

1. Open your group's dashboard calendar. See Managing Calendar Events if you need to create the event first.
2. Open the event you want people to register for, or create a new one.
3. Switch on Enable Forms ("Allow sign-up and registration forms for this event").
4. Save the event.

On a new event, saving takes you straight to the forms setup page. On an existing event, a list of that event's forms appears inline in the event editor, along with a Manage forms link that opens the full Forms page.

Adding a FormCopy Anchor Link

From the event's Forms page:

1. Click Add Form.
2. Either pick one of the three form-type cards and click Create Form, or scroll to Or start from a template and click a starter template -- a template creates the form as soon as you click it, with no Create Form step.

Either way, Hubara creates the form and takes you straight to its editor.

Each row on the Forms page carries three icon-only buttons on the right: a people icon (View responses), a pencil (Edit form), and a red trash can that deletes the form, every response on it, any files uploaded with them, and the website page Hubara created for it. Hover for the tooltip if you are unsure which is which.

The three form typesCopy Anchor Link

The built-in starter templatesCopy Anchor Link

The four built-in templates are offered unless an organization administrator has hidden some of them, which is done from Form Templates in the org's admin settings (/dashboard/admin/settings/form-templates). If your organization has org-authored templates turned on and you are an organization administrator, the form editor also shows Save as Template, which saves a finished form as a reusable template; saved templates then appear in this picker badged Your org alongside the Built-in ones. See Features your administrator controls.

Note: An event can have more than one form -- for example a registration form and a separate food signup. Use the up and down buttons next to each row on the Forms page to arrange the order they appear in.

Building the FormCopy Anchor Link

Click the pencil (Edit form) on the Forms page to open the form editor. Its tab strip reads, left to right: Basic Information, Form Builder, Pricing, Limits, Confirmation, Response View. Pricing, Limits, and Response View only appear for the Form type, so a Signup or Slots form has three tabs rather than six.

Pricing is covered separately in Pricing and Payments Setup -- it is the third tab in the strip even though this guide reaches it last.

The Form Builder tab looks different depending on the form type you picked -- a Form gets a field palette and canvas (below); a Signup gets Contact Information and Categories cards where you add the items people can claim; Slots works the same way, with Slot Groups of time blocks instead of categories of items. The rest of this section covers the Form type -- Signup and Slots share everything else described here (Basic Information, publishing, responses).

Basic InformationCopy Anchor Link

Give the form a Title and an optional Description. Set an Open Date and a Close Date if registration should only be available during a window -- outside it, visitors see the page but can't submit.

Two toggles live here:

• Requires approval before confirming -- submissions arrive with a pending status and stay that way until you approve them from the responses list.
• Members only -- restrict submissions to active members of this event's group. Three things are worth knowing before you rely on it:
  • It restricts submitting, not seeing. The page stays public; a visitor who isn't eligible gets a Members-Only Registration panel where the form would be -- with a sign-in link if they aren't signed in, and "Your account isn't a member of this group" if they are signed in but not a member.
  • "Member" includes delegates. Someone who holds an active delegation to act for a member of that group can submit too, which is what lets a parent register on a member's behalf.
  • It is a feature your administrator can switch off for the whole organization. While it is off, a form marked members-only accepts submissions from anyone, and the toggle itself disappears from this tab -- so if you don't see it here, this form is public no matter what was saved on it before. See Features your administrator controls.

Form BuilderCopy Anchor Link

Drag a field from the palette on the left onto a section in the canvas. New sections start out named "New Section" -- rename them to whatever makes sense for your form.

The top of the canvas always shows a locked Your Contact Details section. Every registration collects the registrant's own Name and Email there -- they are always required, and the confirmation email (when enabled) goes to that email address. Turn on Collect phone to also require a phone number. You don't need to add your own name or email fields for the person filling in the form; add fields only for the people being registered, such as an attendee's name or an emergency contact.

Click a field to open the Field Properties panel on the right. It shows up to four tabs -- which ones depends on the field type:

A Primary field toggle also appears on the Properties tab, but only for a field inside a per-attendee (repeating) section -- the field you mark as primary names each attendee in the response table and the attendee export.

Use Preview at any time to see the form the way a registrant will.

Collecting attendeesCopy Anchor Link

The attendee controls are a strip at the top of the Form Builder tab, above the canvas -- not a tab of their own.

Turn on Collect attendees if one submission should cover several people -- a parent registering three children, for example. Attendees per submission is a choice between One attendee per submission and Several attendees per submission, and Attendee detail says how much you know about each one: Chosen from the people the submitter may register, Named by whoever submits, or Counted only, no names. With Several selected you can also set Minimum attendees and Maximum attendees.

If you don't see Collect attendees, attendee authoring is switched off for your organization. That only stops you adding attendee settings to a form -- a form that already has them keeps collecting, pricing, and cancelling per attendee either way. See Features your administrator controls.

LimitsCopy Anchor Link

Set Max Participants to cap how many people can register (leave it blank for unlimited). Turn on Enable waitlist, and optionally a Waitlist Limit, to keep taking submissions after the cap is reached -- those submissions get a Waitlisted status instead of being refused. Without a waitlist, registrants who arrive after the cap is reached see "This event is currently full and is not accepting new registrations."

On a form that collects attendees, Max Participants and Waitlist Limit count each person -- every attendee and guest -- rather than each submission. A household registers together or not at all: if it is larger than the spots that are left, the registrant is told before submitting, and the whole household joins the waitlist (or, with no waitlist, they're asked to remove people to fit). On any form, Waitlist Limit is enforced: once the waitlist is full, new submissions are refused.

ConfirmationCopy Anchor Link

Write the Confirmation Message registrants see after they submit (it defaults to "Thank you for registering! We'll see you there."). That message is also included in the confirmation email.

Send confirmation email is on by default -- turn the switch off to stop registrants getting an email. While it is on you can set an Email Subject; leave it blank and the subject is "Registration Confirmation — " followed by the form's title.

Put an address in Registration Contact Email and that person gets an email every time a new registration comes in; leave it blank to turn those notifications off. That same address is used as the reply-to on the confirmation email sent to registrants, so anyone who replies to a confirmation will see it -- use an address you are happy to share with everyone who registers.

Response ViewCopy Anchor Link

This tab controls which of the form's fields are shown as columns in the responses table by default. Anyone viewing the responses can still turn individual columns on and off from the table's own Columns menu.

Note: Click Save Changes before leaving the editor -- switching tabs keeps your edits, but navigating away does not.

Pricing and Payments SetupCopy Anchor Link

The Pricing tab is where you set up what a registration costs. This section covers setting the price; what the registrant sees when paying is under What Registrants See, and handling payments afterwards is under Managing Payments.

Before you can charge for a registration, your organization's Square account has to be connected by your platform administrator. This is done in the Hubara management console, not in your dashboard -- there is no place in your org's admin pages to enter Square credentials. If the Enable payment collection toggle is on but registrants see a payment error, contact your platform administrator.

1. Turn on Enable payment collection. While it is off, the tab reads "Payment collection is off. Registrants submit without paying."

2. Choose a pricing model:

   Pricing model	How the price is worked out
   Flat Rate	Single fixed price
   Per Person	Price multiplied by number of participants

3. Enter the amount -- Amount (USD) for a flat rate, or Amount per Person (USD) for per-person pricing.

Processing feesCopy Anchor Link

Turn on Add processing fee to account for card-processing costs. Enter a Percentage (%), a Fixed Amount ($), or both. The fee applies only to online card payments -- registrants who pay in person with cash or check are never charged it.

Pass fee to registrant decides who covers it. Turned on, the registrant pays the fee on top of the price. Turned off, your organization absorbs it out of the amount collected.

Paying in personCopy Anchor Link

Allow pay in person lets registrants submit without paying online and settle up with cash or check at the event instead. Registrants who want to pay by card should still pay online.

In-person payments are off by default. They are a separate feature your platform administrator has to turn on for your organization, and most organizations have not. While they are off, Allow pay in person is not on this tab at all and Record payment is not on a response -- so unless you have had it enabled, every registration on a priced form is paid online through Square or not at all. See Features your administrator controls.

Publishing the FormCopy Anchor Link

A form has exactly three statuses, set from the status badge next to it on the Forms page -- click the badge to open the picker. If you can't manage events for this group the badge is there but not clickable.

There is no separate Closed status, but you have three ways to stop new submissions: set a Close Date, move the form back to Draft, or Archive it once the event is over. Use a Close Date for a planned cutoff, Draft if you need to keep editing and reopen later, and Archive when the event has happened and the form is done for good.

Two things get published, not oneCopy Anchor Link

This is the part that trips people up. There are two pieces: the form itself, and the page on your website that displays it.

Hubara creates that page for you when you create the form. It uses the Event Registration Form template (see Page Templates) and appears in your pages list like any other page. You do not edit its content there -- the form editor controls what it shows. But like any page, it has to be published before visitors can reach it.

PublishingCopy Anchor Link

1. On the Forms page, change the form's status to Ready for Submissions.

2. A Publish registration form? confirmation appears.

3. Choose an option:

   If you see	It means	Choose
   Publish and Publish & View Form	The website page is already published	Either -- Publish & View Form opens the public page in a new tab so you can check it
   Publish Form Only and Publish Form & Page	The website page is still a draft, so visitors cannot reach the form yet	Publish Form & Page in almost every case

In the second case an amber warning explains why: the website page for this form isn't published yet, so visitors won't be able to reach the form's address until it is.

Note: If you only see Publish Form Only, you don't have permission to publish pages for this group. Publish the form, then ask a group or organization administrator to publish its page.

Taking a form back downCopy Anchor Link

Set the status back to Draft. A Move form to draft? confirmation appears, offering Move to Draft or Move to Draft & Edit Page if you also want to update the website page. The form stops accepting submissions immediately, and every response already collected is kept.

If the calendar event itself is cancelled, the registration page closes automatically and shows an "Event Cancelled" notice -- you do not have to unpublish anything, and existing responses are kept.

What Registrants SeeCopy Anchor Link

It helps to know what you're about to publish. Here is the registrant's side of a Form-type registration.

The form is presented one step per section, with a progress indicator reading "Step 1 of 3" and Back and Next buttons to move between steps.

• The first step always starts with Your Contact Details: the registrant's own name, email and (if you collect it) phone. Registrants who are signed in find these filled in from their account and can change them. Someone registering another person enters their own details here and the other person's in the rest of the form. The review step shows "Confirmation will be sent to" that email when confirmation emails are on.

• If the form collects attendees, the first step is Who is attending?, where the registrant lists or picks the people the submission covers.

• On a free form, the button on the last step is Submit.

• On a priced form, the last step's button is Review Order, which opens a Review Your Order step listing what is being paid for and the total.

• From the review step, the registrant clicks Proceed to Payment and pays on the Payment step. Square's Payment Information panel shows the total amount, a card field, and a Pay $X.XX button. Hubara never stores card numbers -- the card details go straight to Square.

• If in-person payment is turned on for the form, the review step offers Pay in Person alongside Pay with Card, and tells the registrant the amount due if paying in person, which excludes the processing fee.

After submitting, the registrant sees the Confirmation Message you wrote, and gets the confirmation email unless you turned Send confirmation email off.

Signup and Slots forms work differently for registrants -- instead of a multi-step form, they see a board of items (Signup) or time blocks (Slots) and claim one directly, providing their contact information at the same time. There's no Review Your Order step and no payment step: Signup and Slots forms cannot collect payment at all -- the Pricing tab exists only on a Form.

What registrants may see insteadCopy Anchor Link

• The event is full. "This event is currently full and is not accepting new registrations." Raise Max Participants, or turn on the waitlist.
• They aren't a member. A Members-Only Registration panel: "This event is only open to members of [group]." Signed-out visitors get a Sign in to continue link; signed-in non-members are told their account isn't a member of the group.
• Registration isn't open. A Registration Closed notice -- "Registration opens on ..." if the Open Date hasn't arrived, "Registration closed on ..." if the Close Date has passed. An archived form shows Registration Archived.
• The event was cancelled. The page shows an "Event Cancelled" notice instead of the form.
• The form is missing its contact details section. A Registration Unavailable notice. This only affects forms created before the contact section existed that were not updated; contact your platform administrator.

Tip: Use Preview on the Form Builder tab to check your questions before publishing, and Publish & View Form to see the real page once it is live.

Viewing ResponsesCopy Anchor Link

There are three ways in, depending on how much you want to see at once.

One form's responsesCopy Anchor Link

From the Forms page, click the people icon (View responses) on the form you want.

At the top is a stats strip: Total, Waitlisted, and Cancelled always; Approved as well if the form requires approval; and Revenue on a Form-type form that has a pricing configuration saved -- including one where Enable payment collection is switched off, where it simply reads $0.00. A form with Max Participants set also shows a Capacity tile -- approved against the cap, in red when it is over. On a form that counts people, Approved and Waitlisted each add a line saying how many people those registrations hold.

Below it is the response table. What tabs it has depends on how the form is set up:

• A plain form with no attendee settings and no primary field shows no tabs at all -- just the table.
• By Submission gives you one row per submission: Name, Email, Status, Payment, and Submitted.
• By Attendee appears when the form collects attendees, or when a field in a repeating section is marked as the primary field. It gives you one row per person -- Attendee, Registered By, Status, Submitted, plus an Attendee status column on a form that actually collects attendees. It is labelled after the section holding the primary field (for example By Participants); with no such section it simply reads By Attendee. This is the tab you land on whenever it exists.
• Not responded shows who in the group hasn't signed up yet. It only appears when attendees are chosen from the people the submitter may register or counted only -- not when they're typed in by name.

Above the table, on the right, sit three controls: Export CSV, Columns (add or remove columns for the form's own fields -- absent on a form with no fields to show), and Filters, which opens a filter panel and then reads Hide filters. The panel filters on Status, Payment, Waitlist (All / Active only / Waitlisted only), and a Submitted date range, with a Clear button once anything is set. Your filter choices go into the page URL, so a filtered view is a link you can share.

What Export CSV actually gives youCopy Anchor Link

Export CSV downloads every response on the form. It deliberately ignores the filters and the Columns choices above it -- narrowing the view on screen does not narrow the file, and hiding a column does not remove it from the export.

Every one-row-per-submission file starts with the same fixed columns -- id, name, email, phone, status, waitlisted, payment status, payment amount, payment method, amount collected, submitted, admin notes -- followed by one column per form field, taken from the form's schema so a question nobody answered still gets a (blank) column.

Each form-field column is named after its section and question: Submission: <section> / <question> for questions asked once per registration, or Attendee: <section> / <question> for questions asked about each attendee. So a question labelled "Email" never overwrites the registrant's email column, and two questions with the same name in different sections stay separate. If two columns would still end up with the same name, the later one gets (2), (3) and so on. Answers to questions that have since been deleted from the form appear under Submission: field_<id> (or Attendee: field_<id>). In a one-row-per-submission file, each question in a repeating section gets its own Attendee: column, with every entry's answer separated by commas.

Choices export as their labels rather than stored values, and yes/no questions export as Yes or No.

The row grouping depends on the form:

• A form that collects attendees exports one row per attendee, not one per submission. The submission's shared answers are repeated on each of its rows, and three extra columns are added: attendee name, attendee status, attendee amount.
• Every other form exports one row per submission. A form with a repeating section can also export one row per entry -- see below.
• Signup and Slots forms add a column listing the items or slots each response claimed.

On a form with a repeating section that does not collect attendees, Export CSV opens a menu with Export by submission and Export by <section title>. The second gives one row per entry in that section. Each row leads with the primary field, or with "Attendee 1", "Attendee 2"… when no field is marked primary. It has no payment columns, and its file name ends in -by-attendee.

Selecting rows with their checkboxes reveals bulk actions, and what they do depends on which tab you are on:

• By Submission gives you Approve all and Cancel all, acting on whole submissions.
• By Attendee, on a form that collects attendees, gives you a single Cancel N attendees. It acts on just the people you ticked and leaves the rest of each registration alone. It warns you first if cancelling those people would leave a registration with nobody on it, and it moves no money -- refund separately if one is due.
• By Attendee on an older form that has no attendee list keeps the bar disabled and points you back to By Submission.

Either way you are asked to confirm, and neither can be undone.

Click a registrant's name (or attendee name) to open that response in detail. Rows are not clickable as a whole -- the name is the link. The detail page shows the status badge and the available actions, an Attendees list on a form that collects them, and then the cards that apply to that response:

• Form Responses -- the submitted answers, on a Form-type response. Files uploaded to a File Upload question appear inline with that question.
• Signup Selections -- the items claimed, on a Signup response. It takes the place of Form Responses there.
• Slot Selections -- the time blocks claimed, on a Slots response. Likewise in place of Form Responses.
• Attachments -- only for files that aren't tied to a question: Signup and Slots responses, and older Form responses.
• Payment -- on a form that collects payment.
• Admin Notes -- read-only, and only when a note has been set on the response. This is the same text that fills the admin notes column in the CSV export.

Waitlisted registrationsCopy Anchor Link

Waitlisting is configured only on a Form: turn on Enable waitlist, and optionally set a Waitlist Limit, on the Limits tab. Once Max Participants is reached, new submissions come in with the Waitlisted status, are counted in the Waitlisted stat tile, and can be isolated with the Waitlist filter (All, Active only, Waitlisted only). Approve one from the response list the same way you would any other submission.

Signup and Slots forms have no waitlist settings -- their capacity is set per item or per slot when you add it.

Signup and Slots overviewsCopy Anchor Link

Below the response table, a Signup or Slots form has a second set of tabs. A Signup form gets Signup Overview (claims grouped by category) and a Slots form gets Slot Overview (claims grouped by time block); both also get a Waitlist tab listing anything on that form currently waitlisted, with a control to promote a person off the list. These are the quickest way to see who claimed what, separate from the response table above. A Form-type form has no overview tabs -- its waitlist lives in the Waitlist filter described above.

All responses for one eventCopy Anchor Link

Use View all responses on the event's Forms page.

If the event has only one form, this takes you straight to that form's responses. If it has several, you get a card per form with its own totals and a View responses button.

Every event in a groupCopy Anchor Link

Use the Registrations link in the group's dashboard navigation, at /dashboard/[group]/registrations. It lists the calendar events in that group that have registration forms, newest first, each with Forms and Responses buttons. If no event in the group has a form yet, it shows "No events with registration forms".

Note: You can't edit a registrant's answers after they submit. If something is wrong, cancel the registration and ask them to submit again.

Managing PaymentsCopy Anchor Link

Payment status shows up in two places: the Payment column on the By Submission tab of the responses table, and the Payment card on an individual response.

The card always shows Status, Method, and Amount. Three more rows appear only when they apply: Collected ("$X of $Y") while the payment is partially paid, Processing fee when a fee was charged, and Receipt with a View receipt link for a payment taken online through Square. Any in-person payments you have recorded are listed underneath, under Recorded payments.

Which actions you'll seeCopy Anchor Link

A response only offers the actions that make sense for its current state, so a given response rarely shows all four.

ApprovingCopy Anchor Link

If the form requires approval, submissions arrive pending and stay there until you click Approve on the response (or select several rows and use Approve all).

Approving a registration that would take the form past Max Participants asks you to confirm first and shows where it would leave the form -- for example "This puts the form at 42 of 40 people." You can still go ahead. Approve all includes the same line in its confirmation.

CancellingCopy Anchor Link

Cancel on a response stops that registration counting toward capacity, which frees up a spot. On a form that counts people, cancelling one attendee frees that one spot, even while the rest of the household stays registered. It does not delete the response, and it does not refund anything -- if money changed hands, refund it separately. Cancel is withheld on a partially paid registration for exactly that reason.

RefundsCopy Anchor Link

Use the Refund action on the response and confirm in the Refund Payment dialog.

Important: If the registration was paid online, refunding it here processes the refund through Square automatically. Do not also issue a refund from the Square dashboard -- the registrant would be refunded twice.

If Square declines the refund -- usually because your Square account and its linked bank account couldn't cover it -- Hubara shows an error and leaves the registration unchanged. No money was returned, and trying again in Hubara won't help. Issue that refund from the Square dashboard instead; this is the one case where refunding in Square is correct, because Hubara moved no money. Afterwards Hubara will keep showing the registration as paid, and its revenue totals will still include that payment, which is expected, since the refund happened outside Hubara. Don't use Hubara's Refund on that registration (or that attendee) afterwards -- the money has already gone back, and a second refund could go through.

Recording an in-person paymentCopy Anchor Link

Record payment only appears if your organization has in-person payments turned on, which is not the default. See Features your administrator controls.

1. Open the response.
2. Click Record payment. The Record Payment Received dialog tells you the remaining balance.
3. Choose a Method: Cash, Check, In-person card, or Other.
4. Enter the Amount (USD). It cannot exceed the remaining balance -- a larger amount is rejected with the balance quoted back to you.
5. Add a note if it helps -- a check number, for example (up to 500 characters).
6. Click Record Payment.

You can record part of the amount. The response then shows "Collected $X of $Y" until the balance is settled, and you can record further payments against it; once the recorded total reaches the amount owed, the payment flips to Completed. Recorded payments are a permanent log: if you enter one by mistake, correct it with a refund rather than trying to delete the entry.

Features your administrator controlsCopy Anchor Link

Four parts of event registration are switched on and off per organization by your platform administrator, not by you. If a control described in this guide isn't where it says it is, one of these is the reason.

Because in-person payments are off unless someone deliberately turned them on, treat every reference to Pay in Person and Record payment in this guide as conditional on that.

ReferenceCopy Anchor Link

Form statuses -- set on the Forms page.

Registration statuses -- the status of one person's registration. The status badge in the responses table shows the short form (pending, approved, ...); the filter panel spells them out.

Payment statuses -- see Managing Payments for what each one means. The badge and the filter panel word two of them differently.

Field types -- what you can drag onto a Form-type form.

TroubleshootingCopy Anchor Link