After you create a new event, a series of decisions is waiting for you that will shape the rest of your work. Some of them cannot be changed afterward — primary language is the typical example — others can be edited, but at the cost of redoing earlier work. This article walks you through the recommended order of those first steps so you do not have to come back to the basics later.
Fill in the basic event information (name, time, type, languages) when you create it.
Confirm the primary language right away — it cannot be changed later without creating a new event.
Decide on the registration type and the event's visibility before you publish any link.
Plan attendee groups and categories up front, not later when problems appear.
Only then move on to content and engagement features.
When you create the event, you fill in:
Event name and an icon (you can add the icon later).
Time zone — set automatically from your browser, but verify it.
Event start and End of event.
Event type — In-Person, Virtual, or Hybrid. An In-Person event gives the attendee access to both the mobile app and the web app, a Virtual event gives access to the web app only, and a Hybrid event opens both.
Primary language.
The primary language is the event's fallback language. When an attendee opens the microsite or the app with their device set to a language the event does not have explicitly added, the content shows in the primary language.
For example, if you have two content languages — Czech and English — and you expect international guests with their devices set to German, Spanish, or other languages, the primary language should be English. Otherwise they will see Czech. If your event has international attendees, English as the primary language is almost always the right call.
The primary language is set when you create the event and cannot be changed later without creating a new one. It is one of the few decisions in Happenee that is genuinely irreversible. Give it the attention it deserves.
Before you open registration, decide:
Public vs. closed registration — will you share a public link, or invite attendees with a personal link? A public link can spread to outsiders; a personal link keeps you in control.
Domain restrictions — do you want to allow registrations only from a specific company domain? Configuring allowed or blocked domains requires customer support.
Nominations — should registrations come through nominators (for example, a sales team that invites their own clients)?
Approval — do you need to approve registrations manually before the attendee gets into the event? Note: Approved registration can only be set up for free events.
Automatic registration after ticket purchase vs. Registration with additional information — should registration be confirmed instantly, or do you need the attendee to fill in extra details in a form?
Each of these choices shapes the flow and the way you manage registrations. Deciding before launch is far easier than fixing things later.
Beyond the registration type, an event has two important settings that determine what the attendee sees in the attendee app:
Event visibility in the attendee app — either only for contacts assigned to the event (the default), or for all contacts in your workspace. The second option works well for internal corporate events where you want all colleagues to see the event lineup, even if the organizer did not invite them explicitly.
Event access in the app — either only after filling in the registration form (the default), or without any form at all (one click on the event sets the status straight to Attending). The second option is useful for internal events where you do not want to make colleagues fill in anything.
Combining these two settings with the registration restriction gives you flexibility for very different event types — from strictly invitation-only to fully open company gatherings.
In Access and registration settings, you can choose:
No restrictions — anyone with the link can register.
Only assigned contacts — even if you have a public microsite link, only contacts assigned to the event in advance can register.
Allowed domains only — registrations only from selected company domains (configured by customer support).
Block registration from specific domains — blocks registrations from selected domains (configured by customer support).
Default account (workspace) settings — a global restriction that applies to every event in the workspace (configured by customer support).
You can also set a maximum number of attendees, a registration deadline, and the option to cancel.
Groups are one of the most underused tools in Happenee. They power:
Communication targeting — choosing who receives which e-mail.
Visibility control — which group sees which content or engagement feature.
Conditional questions in the Registration form — for example, a meal question that only appears for VIP attendees.
Reporting — filtering statistics by group (for example, "how many people from colleague Novák's nominations actually attended").
The rule is simple: groups you want to use have to be planned in advance. As an attendee goes through registration, they get assigned to a group based on what they choose in the form — and that has to be set up. Assigning groups after the fact works in bulk, but it is extra manual work.
Content features live in the Content section. They make up the informational backbone of the event and show on both the microsite and the attendee app (where it makes sense):
Agenda
Speakers
Venue
Contact
Custom content (any text, images, FAQ, map, info block)
Sponsors
Exhibitors
You add them with the + Add button and fill them in step by step. For each content feature, you decide whether it shows on the microsite, in the app, or both.
Engagement features actively involve the attendee inside the app:
QR ticket (engagement feature; the related module is Tickets)
Notifications (push notifications and news in the news feed)
Polls (interactive polls and contests)
Questions (audience questions)
Survey (feedback)
Networking and meetings between attendees
Registration information (an overview of what the attendee filled in during registration)
Online module (livestreams, 3D environments, supplementary content)
Not every event needs every engagement feature. Turn on only the ones that genuinely make sense. Empty enabled features look worse than features that are simply not there.
Every content or engagement feature has its own visibility toggles. Typically, you can set:
Show in the app yes/no
Show on the microsite yes/no
Show only to selected groups (visibility)
That means you fill in the content once and control its targeting separately.
If your event has international attendees, the primary language is English. Make this decision when you create the event, not when you publish registration — afterward, it cannot be changed.
Plan your group structure before registration goes live. Think about who you want to differentiate (VIP, standard, speakers, partners, client segments) and create the groups in advance, so the registration form can assign attendees to them automatically.
Empty features look unfinished. Turn on only the ones you will fill in. For smaller events, less is always more.
Decide on the registration type (public, closed, nominated, approved) before you publish any link. Mid-flight changes create chaos in attendee data.
