Advanced: Events

For users who already know the basics — this guide covers the event wizard in depth, the distinction between event teams and tenant teams, invite link security model, bulk application processing for high-volume recruitment, auto-publish behaviour, and managing the full event lifecycle.

The Event Wizard in Depth

The wizard is the only way to create an event. There is no shortcut form. This is intentional: events have structural dependencies (teams, locations, patterns) that must be set up together or the scheduling grid won't render correctly.

The wizard saves progress to a session after each step — you can close the browser and return later without losing work. The in-progress state is visible on the Events index page as a "Draft" entry.

Step sequence:

1. Basic info — name, description, start and end dates.
2. Structural toggles — decide these carefully before moving on; changing them after the event is fully built requires more manual work:
   • Use teams — enables the row axis in the schedule grid. Without this, all shifts live in a single unorganised pool.
   • Multiple locations — lets you link more than one venue. Without this, the event has at most one linked location.
   • Auto-publish — see the Auto-Publish section below.
3. Teams — create the event-scoped teams. Names can match your tenant teams (e.g., "Security", "Bar Staff") but they are entirely separate rows in the database.
4. Locations — link existing locations or create new ones. If you add a client at this step, it propagates to all linked locations.
5. Shift patterns — import global patterns and/or create event-specific ones. Event-specific patterns won't appear in other events or location schedules.

After saving, the event status is draft. Move it to active via Update Status when you're ready to build the schedule and roster.

Event Teams vs. Tenant Teams

This is the single most common source of confusion in the module.

You cannot assign a tenant team to an event or vice versa. If your Festival has the same team structure every year, you'll need to re-create the event teams for each new event. Consider documenting your standard team structure (names, headcounts) outside the system to speed up setup.

Invite Link Security Model

Invite links are publicly accessible URLs — no login required. Anyone with the URL can submit an application. This is by design for external recruitment, but it means the token is the only access control.

Key security properties:

• Each link has a unique token generated on creation. Tokens are long random strings.
• Links can have an optional password — applicants must enter it before the form loads.
• Links can have an expiry date — after which the URL returns a closed-application page.
• Each link can have a label (e.g., "Instagram campaign", "Referral from partner agency") for tracking which channel produced which applicants.

Treat tokens as secrets. Do not share them over public channels unless you intend for everyone to see them. If a link is compromised (spammed, shared unintentionally), deactivate it and create a new one — old applications from that link remain in the system.

The public link grants write access. Anyone with the URL can submit an application form that lands in your inbox. There is no CAPTCHA or rate-limiting in v1. If you're running a high-profile public campaign, be prepared to filter noise from bulk or fake submissions in the Applications tab.

Bulk Application Processing

For events with large applicant volumes (festivals, one-day staff calls), the bulk approve/reject action on the Applications tab is the only practical way to work.

How it works:

1. Filter the applications list to show only the status you want to process (typically Pending).
2. Use the checkboxes to select applications, or select all on the page.
3. Click Bulk Approve or Bulk Reject.
4. For rejections, you can enter a single note that applies to all rejected applications.

Approved applicants are immediately converted to event members and receive a notification. They can then see the event in their Meine Schichten once shifts are published.

Practical tip: During fast-moving recruitment, use the label on each invite link to segment your processing. Sort by label, approve all from your primary channel first, then review the rest.

Auto-Publish Behaviour

When auto_publish is enabled on the event, every shift slot you create or edit is immediately published — there is no separate publish step.

Consequences:

• Employees assigned to any slot see it in their Meine Schichten the moment you save.
• Shift notifications fire immediately on creation, not after a batch publish.
• There is no "draft before publish" safety net. Saving is publishing.

When to use auto-publish:

• Rapidly-evolving events where the schedule changes continuously and you want employees to see the latest version immediately.
• Small internal events where the organiser is also the only scheduler.

When to avoid auto-publish:

• Large events where you build the schedule incrementally over several days and don't want half-finished drafts visible to staff.
• Events involving external applicants who might get confused seeing tentative shifts before finalisation.

You cannot toggle auto-publish off after the event is created — the toggle is set in the wizard. If you need to disable it, contact your admin; it requires a direct edit of the event record.

Event Lifecycle Management

Events progress through four statuses. Move between them via the Update Status button on the event show page.

There is no automatic status transition. You must manually move the event when it ends. Until you archive it, the event stays in your active list.

Archiving tip: Archive events promptly after completion — a long list of old active events makes the schedule grid navigation unwieldy. Archived events retain all their data (shifts, applications, roster) and are fully accessible for reporting.

Related Guides

• Modules-Events — basic setup and daily workflow
• Advanced: Schichtplanung — shift rules and conflict detection that also apply to event schedules