Required Forms and Waivers
Hubbaly uses required forms to enforce event readiness and legal/compliance workflows.
Mental Model
- Community creates reusable templates.
- Event attaches templates or custom forms.
- Event publishes form versions.
- Ticket holder and guests sign required forms.
- Scanner enforces completion at check-in.
Organiser Setup Flow
- Create community-level templates in hub admin documents.
- Attach templates (or create custom forms) in event admin documents.
- Mark each document as required or optional.
- Publish versions before event day.
- If re-sign is required on a new version, attendees must sign again.
Event admin now treats this as part of the broader Forms workspace. Required signed documents, waivers, and consent remain separate from private feedback forms:
- Signed waivers and required forms are enforced by the documents workflow.
- Feedback forms collect private organiser feedback after or around an event.
- Feedback is not public reviews, ratings, reactions, polling, or a feed.
Hub Document Templates
Use Hub -> Admin -> Forms & Docs to keep reusable event material in one place.
The hub page now has two template areas:
Document templatesare signed documents: waivers, release forms, media consent, or repeat event policies. Document templates can include form fields when the signer must supply more than a signature, such as legal name for ID matching at the door.Form templatesare non-signed forms for participant information, onboarding, and private organiser feedback. They do not create signed readiness records and they do not unlock ticket QR codes.
Keep template titles obvious so event operators know exactly what to attach. Use merge fields when signed wording needs event-specific details like event name or signing time.
Attaching a document template to an event creates an event-level document copy. The event-level document is what gets marked required or optional, published, and enforced by ticket readiness and scanner checks. Editing the hub template later does not silently rewrite a live event document.
Use Event -> Admin -> Documents (the Resources & Forms page) to attach templates, publish
versions, and handle re-signing.
Form Fields on Required Documents
Form fields collect a small amount of typed signer information as part of the same required-document signing flow.
- Use them when the signer must provide a concrete answer, not just read markdown and sign.
- Good examples are legal name for ID matching at the door, emergency contact or accessibility notes, short acknowledgements, and required checkbox confirmations.
- Supported field types are
Legal name, short text, long text, and required checkboxes. - If a document includes
Legal name, Hubbaly uses that answer as the signature name for that document instead of asking for a separate signer-name input. - If a document does not include
Legal name, the ordinary signer-name prompt stays in place. - If
Legal nameis present and left blank, the signer cannot finish the document. - Previously entered
Legal namecan stay in the draft while the signer is still editing, and editing the field updates the pending signature name before submission. - There is never a second competing signer-name input when
Legal nameis present in the same signing flow. - They are not a separate workflow outside the document, and they are not a replacement for longer operational questionnaires.
- Required form fields must be completed before the signature is accepted.
Event Admin Required Forms
Use Event -> Admin -> Documents to manage what applies to this one event.
- Attach an existing hub template when you want consistency.
- Create a custom document when the wording is event-specific.
- Mark items as required only when they must block readiness.
- Publish updated versions before event day, not during active check-in unless necessary.
The same admin route can also show a Feedback forms tab. Use it only for private organiser feedback that does not require a signature.
Event Feedback and Responses
Use feedback forms when organisers need a private post-event debrief from people who actually held a ticket.
Good examples:
- “What should we change before the next ride?”
- “Was the arrival information clear?”
- “Did you have any access or safety issues we should fix privately?”
- “Would you be comfortable being contacted by the organiser about this response?”
Feedback responses are not public reviews, ratings, reactions, polls, or a feed. They stay in Event
Admin under Documents -> Feedback forms. Choose a form in the list, then use the Responses panel
to read submissions or Export CSV for offline review.
If Allow anonymous feedback is enabled, participants can choose whether to hide their name from the
organiser response view and export. Hubbaly still keeps the ticket/attendee link internally for
integrity and duplicate prevention. This is useful when you want candid operational feedback without
turning feedback into a public reputation system.
Attach Template to an Event
Use Attach Template when the hub already has a reusable document that should apply here.
- Choose the correct template from the list.
- Confirm the wording is right for this event before attaching.
- If the right template does not exist yet, create it in hub admin documents first.
Ticket Holder Flow
- Open your ticket.
- Open the forms/documents section.
- Complete any required form fields.
- Sign all required items.
- Return to ticket and verify readiness state.
Guest Flow
- Ticket owner or admin sends guest signing link.
- Guest opens secure link and signs without full app access.
- Completion status syncs into ticket readiness.
- Scanner checks owner and guest completion for required items.
Event-Day Enforcement
Scanner checks required forms before normal validation.
If forms are missing:
- Attendee/guest signs first, then re-scan, or
- Authorized operator uses explicit override where policy allows.
Override Rules
OWNERandADMINcan override.- Event staff can override required document checks only when an owner/admin grants that explicit staff permission.
- Overrides should be controlled exception handling, not default workflow.
Consent Overview and Attendees
Use the participant readiness/consent overview screens when you need to see who is ready and who is blocked.
Completion Summaryshows overall readiness at a glance.Required Formsshows which forms are current and whether re-signing is needed.Attendeeslets you review who is complete, incomplete, or needs to re-sign.- Event Admin
Attendance,Event Day, orAttendance recordsalso composes registration status, waiver status, and feedback completion without changing scanner enforcement. The label changes with the event phase, but it is the same roster/readiness route.
This is an operator review screen. The canonical workflow for changing documents still lives in Event -> Admin -> Documents.
Common Failure Cases
”I signed but still blocked”
- Check if a newer form version now requires re-sign.
- Check whether a guest on the same ticket still has pending required forms.
- Check whether a required form field was left blank on the current published version.
”Guest cannot open signing link”
- Regenerate and resend the guest link.
- Confirm guest is tied to the correct attendee record.
”Scanner says documents required”
- Use scanner pending-doc details.
- Resolve signer-by-signer and re-scan.