/ to search
Documentation Events

Events

Events

Browse tenant guides generated directly from the Markdown files in docs/tenant.

Introduction

In Altrinum, an event is not just a registration page. It is the operational center for everything related to a single occurrence — from setup and registration to check-in and follow-up.

This matters because nonprofit events are rarely owned by one team.

  • Development cares about revenue, donors, and sponsorships
  • Programs care about participation and experience
  • Operations care about capacity, logistics, and check-in
  • Communications care about reminders and follow-up

Keeping all of that inside one event record ensures everyone is working from the same source of truth.

Why events are structured this way

One record supports the full lifecycle

An event record can hold:

  • registration questions and attendee data
  • pricing, tickets, and donation prompts
  • guest handling
  • waitlist behavior
  • communications (confirmation, reminders, surveys)
  • attendance and check-in
  • exports and reporting

This reduces the need to coordinate across multiple disconnected tools.

In practice, it means:

  • the same record used to launch registration is also used on event day
  • the same data used for check-in is used later for reporting
  • staff do not need to reconcile multiple systems after the event ends

Events are designed for one real-world occurrence

An event represents one specific instance in time.

Examples:

  • one gala
  • one workshop session
  • one webinar date
  • one volunteer orientation

If you try to use one event to represent multiple dates, audiences, or flows, things usually become harder:

  • reporting becomes confusing
  • registration logic becomes inconsistent
  • public experience becomes unclear

That is where Programs come in.

Event vs Program (important distinction)

Use an Event when:

  • people are registering for one specific occurrence
  • there is one date (or tightly bound schedule)
  • the experience is singular

Use a Program when:

  • there are multiple sessions or dates
  • supporters should browse across options
  • registrations span a series rather than one instance

A simple rule:

If supporters are choosing which occurrence to attend, you likely need a Program.
If they are choosing whether to attend this occurrence, you need an Event.

Public visibility supports different audience types

Events can be:

  • Public — visible and accessible to everyone
  • Password protected — visible only with a shared credential
  • Hidden — accessible only via direct link

This allows the same system to support:

  • open community events
  • invite-only donor events
  • partner or internal sessions

Registration is more than a form

Registration settings define how supporters move through the system.

That includes:

  • pricing and payment handling
  • guest logic
  • capacity and waitlists
  • donation prompts
  • marketing consent capture

Small changes in these settings can significantly affect:

  • who registers
  • how many people attend
  • how smooth event-day operations feel

Waitlists and attendance are operational systems

Events track registrants through real operational states:

  • pending
  • confirmed
  • waitlisted
  • cancelled
  • refunded
  • checked in

These are not just labels. They support real questions like:

  • Who still needs a reminder?
  • Who has not completed payment?
  • Who is waiting for a seat?
  • Who actually attended?

That is why waitlists and attendance are treated as core system behaviors, not optional add-ons.

Capacity is based on seats, not just registrations

Capacity is calculated using seat usage, not just the number of records.

Seat usage may include:

  • confirmed registrations
  • pending registrations
  • active waitlist offers
  • guest counts or ticket quantities

This is why an event can still appear “full” even after a cancellation.

Historical accuracy is preserved

When tax, receipting, or donation settings are enabled, changes apply to future registrations rather than rewriting past ones.

This ensures:

  • reporting remains reliable
  • financial reconciliation is consistent
  • historical data reflects what actually happened at the time

How events fit into nonprofit workflows

Events often sit at the intersection of:

  • fundraising
  • engagement
  • program delivery
  • community building

Because of that, a well-structured event record supports:

  • campaign alignment (email + events)
  • attendance tracking
  • donor cultivation
  • reporting and compliance
  • post-event follow-up

Tips and notes

Tip

If your event setup starts to feel complicated, it is often a sign that the structure (Event vs Program) should be revisited, not just the settings.

Tip

Test the full registration experience before publishing, especially when using guests, waitlists, and payments together.

Example: A nonprofit could run a public volunteer orientation as one event, while a donor cultivation dinner uses password protection, guest limits, and manual waitlist handling.