Events

Part of the IP4CMS portal. ← All module guides

What it's for — The Events module lets you run member-facing events end to end: you define reusable event types, schedule individual events against them, register members (and optionally guests or anonymous attendees), record who actually attended, and confirm participation. Confirming participation can automatically issue a certificate and can promote a pending member to active. Event types can also carry prerequisites, so a member must complete one event before becoming eligible for another. Where invitations are enabled, you can build an invitee list and send invites in bulk.

Where to find it — In the portal sidebar under Events. The route is /app/events, which opens the events list. A calendar view is available at /app/events/calendar. Event types live under Settings → Event Types (/app/settings/event-types); links from the Events area that point at types redirect there.

Before you start —

• The events licence module must be enabled for the tenant for the module to appear.
• To create, edit or delete events and event types you need the matching event permissions (see Permissions & access). Reading events and event types only requires being signed in.
• Registration uses your member records, so the members module and member data should be in place before you register people.
• Several capabilities are gated behind sub-modules that must be licensed separately: prerequisites (events:prerequisites), automatic member activation (events:member_activation), certificates (certificates), registration/RSVP (events:rsvp or events:registrations), guest and anonymous RSVP (events:rsvp:guests, events:rsvp:anonymous), and the invitation features (events:invite, with bulk upload under events:invite:bulk_upload). If a section described below is missing from your screen, the corresponding sub-module is not enabled.
• Optional integrations: Locations (locations module) to attach a venue, Payment Channels and Products for paid events, Message Templates for invitation emails, and Certificate Templates for issued certificates.

Key tasks

Create an event type

Event types are the reusable templates that every event is based on (for example "Induction", "Annual Training").

1. Go to Settings → Event Types and choose to add a new event type.
2. Fill in the fields:

• Name (required, up to 100 characters).
• Description (optional, up to 1000 characters).

1. If the Prerequisites section is shown (events:prerequisites enabled), pick one or more other event types a member must have completed first, and choose how they are evaluated:

• All — the member must have completed every selected prerequisite type.
• Any — completing at least one of the selected types is enough.
• You cannot select the event type itself as its own prerequisite.

1. If the Member Activation section is shown (events:member_activation enabled), tick Activates pending members to have completion of this event type promote a Pending member to Active.
2. If the Certificate Configuration section is shown (certificates enabled), tick Auto-generate certificate and choose a Certificate template to have a certificate issued automatically whenever a member's participation is confirmed.
3. Save. (Certificate settings are saved separately; if they fail to save you will see a warning while the event type itself is still created.)

Create an event

1. From the events list (/app/events) choose to create a new event (route /app/events/new).
2. Complete the form:

• Event name (required, up to 255 characters).
• Description (optional, up to 1000 characters).
• Event type (required) — pick from the event types you defined.
• Location (optional, only if the Locations module is enabled).
• Start date / Start time and End date / End time (all required). The end must be after the start, or the form will reject it.
• RSVP required — when on, attendees must register in advance. Enabling it reveals:
• RSVP cut-off date / time — the deadline for registering.
• Max attendees — a registration cap (only saved when RSVP is required).
• Allow guests and Allow anonymous — whether non-member guests / anonymous attendees may RSVP (each gated by its own sub-module).
• Requires payment — when on, choose a Payment channel. The form blocks saving if payment is enabled without a channel.

1. If invitations are enabled (events:invite), set per-audience rules for Member, Guest and Anonymous: an optional Product (price) and an optional Message template (the invitation message) for each.
2. Save. You are taken to the event's detail page.

Events can be edited later from their detail page and deleted from the events list (subject to permissions).

Find and view events

• The events list supports a free-text search plus add-on filters for Event type, Location, Start date and End date, and is sortable by name and dates. Each row shows a derived status: Upcoming (before start), In Progress (between start and end) or Completed (after end).
• The calendar view (/app/events/calendar) plots events by date.
• Opening an event shows three tabs: Overview (event details and status), Participants (registered members), and Invitees (if invitations are enabled).

Register members for an event

(Requires the events:rsvp or events:registrations sub-module.)

1. Open the event and start registration (the registration screen lists members and their eligibility).
2. Use the search box to find members by name, email or membership number. The list marks each member as eligible, already registered, or ineligible.

• A member is selectable only if they are eligible and not already registered. Ineligible members show their missing prerequisites.

1. Tick the members to add (or use Select all eligible), then confirm. You are asked to confirm the count before registration runs.
2. On success you are returned to the event's Participants tab.

To remove someone, open the Participants tab and remove the participant; you will be asked to confirm.

Record attendance and confirm participation

• Attendance (the raw "who turned up" record) is managed through the attendance endpoints and requires the Manage attendance permission. You can update a single member's attendance or bulk-update several at once.
• Confirm participation is the formal completion step. From the event's Participants tab, confirm a member as having completed the event. Confirming:

1. Stamps a completion date on the member's event record.
2. If the event type activates pending members, promotes that member from Pending to Active.
3. If the event type has auto-generate certificate turned on, issues a certificate using the configured template — the success message tells you when a certificate was generated.

Completion is what prerequisites are checked against: a member "has" a prerequisite once they have a completed (completion-dated) record for any event of that prerequisite's type.

Manage invitees and send invitations

(Requires the events:invite sub-module; bulk upload requires events:invite:bulk_upload.)

1. Open the event's Invitees tab.
2. Add invitees individually (email, optional mobile, optional linked member, and an invitee type of member / guest / anonymous), or use Upload event invitees to import a CSV with email, mobile, member_email or member_mobile columns.
3. Each invitee carries a send status of pending, sent or failed.
4. Use bulk send to queue invitations for all invitees. This starts a background job and reports how many invitees were included; refresh the list to watch statuses update. The message content comes from the per-audience message template rule set on the event.

How the data connects

• Event types (event_type) hold the reusable definition, including prerequisite type IDs + the all/any operator, the activates-pending-members flag, and the certificate config (auto_generate_certificate, certificate_template_id).
• Events (event) reference an event type and optionally a location and a payment channel, plus schedule, RSVP and capacity settings. Per-audience entity rules attach a product (price) and message template for each invitee type.
• Registration writes event-member records (event_member). Member RSVPs and guest/anonymous registrations (event_registration) both surface in the participants list. Eligibility is computed live by comparing the event type's prerequisites against the member's completed event-member records.
• Confirming participation sets the completion date on the event-member record. That single action can: feed back into members (Pending → Active), satisfy prerequisites for future events, and — via the certificates module — generate a certificate document stored against the member.
• Invitees (event_invitee) are the outreach list; bulk send hands them to the background job and updates each invitee's send status, using the event's message-template rules to drive communications.
• All of this flows back to the member portal / resident app, where members see events, RSVP, and (where enabled) bring guests.

Permissions & access

• Licence module: the events module must be enabled. Individual capabilities depend on the sub-modules listed in Before you start — without them the related UI sections and endpoints are hidden or refused.
• Permissions (admin/portal users):
• events:read:all — view events and event types (reading event types/events themselves only requires authentication).
• events:create:all — create event types, events, and individual invitees.
• events:update:all — edit event types and events, set prerequisites, configure certificates, add invitees.
• events:delete:all — delete event types and events.
• events:manage:attendance — view and update attendance (single and bulk).
• events:invite:bulk_send — trigger bulk invitation sends.
• Entity-rule pricing/template management additionally requires the events:invite and members modules.
• Enhanced permissions also exist for prerequisite, eligibility, participation-confirmation, certificate and dependency management.
• Member registration vs admin: registering or removing members goes through the events:rsvp / events:registrations modules rather than the create/update permissions, so RSVP can be opened up independently of full event-editing rights. Members self-RSVP from the member portal; operators register members on their behalf from the portal.

Tips & gotchas

• End must be after start. The form rejects an end date/time that is not strictly after the start.
• Max attendees and RSVP cut-off only apply when RSVP is required. If you turn RSVP off, those values are cleared on save.
• **Prerequisites are checked against completion, not registration.** A member only counts as having met a prerequisite once their participation in an event of that type has been confirmed (completion-dated) — merely being registered is not enough.
• "Any" vs "All" matters. With the any operator a single completed prerequisite makes a member eligible; with all, every listed prerequisite must be completed.
• Certificates need three things lined up: the certificates module enabled, auto-generate certificate ticked on the event type, and a certificate template chosen. Certificates are only created at the moment participation is confirmed — they are not generated for past completions retroactively.
• Pending → Active promotion is silent and one-way at confirmation time: it only fires when the event type has activates pending members on and the member is currently Pending.
• Certificate settings save separately from the event type. If saving the certificate config fails, the event type is still created/updated and you get a warning — re-open the event type to retry.
• Already-registered members are auto-dropped from a bulk registration selection, with a notice, so you cannot double-register.
• Bulk invite sending is asynchronous. The success toast confirms the job started and the count queued, not that every message was delivered — check each invitee's send status (pending / sent / failed) afterwards.
• Event types live under Settings. Links inside the Events area that mention "types" redirect to Settings → Event Types; manage them there.