How conference software built on one event record works

Three ideas explain almost everything else: events belong to organizations, capabilities are products you switch on per event, and there are two different doors into a program.

Organizations own events

An organization is the society, association or company that runs meetings. Everything else hangs beneath it: its people, its venues, its contact book, its email templates, and its events.

An event is a single meeting — a congress, a workshop, a webinar. Inside it live tracks, sessions, presentations, posters, speakers and files. Almost every screen in Rostrum is scoped to one event, and permission to work on one event grants nothing on another.

Capabilities are products you turn on

Rostrum is not one monolithic feature set. It is a small catalog of products, switched on per event. An event that only needs a schedule and file collection turns on nothing extra. A scientific congress with an open call, poster hall, digital signage and a delegate app turns on five or six.

This is the single most important thing to understand about the platform, and the reason this guide is organized the way it is:

You are never obliged to use all of it. Most events use a third of it. A handful of products do depend on each other — and this guide marks every one of those dependencies where it occurs.

Turning a product off hides its tab, its settings and its participant-facing pages. The data stays; nothing is deleted. You can switch products on mid-flight — a call for abstracts can be added to an event that already has a venue and dates, and signage can be added the week of the show.

Two questions, not one

It is tempting to ask "does my program come from a call for abstracts, or do I already have it?" — but that collapses two separate questions, and collapsing them is how people end up assuming Rostrum is only for the first case.

The two questions are:

Where do the talks come from? A call for abstracts you run, a file you already hold, or your own committee typing them in.
Where does the schedule get built? Which sessions exist, in which rooms, at what times, containing which talks.

Rostrum answers the second one in every case. A meeting with an entirely invited program and no abstracts at all still has tracks to define, rooms to fill, sessions to lay out and a running order to settle — and that work belongs here, not in a spreadsheet you later import.

Importing is how you bring a program that already exists. It is not the only alternative to a call for abstracts — building it here is.

Three sources, one place the schedule lives. A call for abstracts and direct entry both hand Rostrum a pile of talks that still need arranging; the spreadsheet import is the one route that brings the arrangement with it, which is why it can look like a peer of the call rather than what it is — a way of onboarding a program that already exists. Everything downstream behaves identically regardless of route.

Time is always venue time

Every date and time you see or type in Rostrum is wall-clock time at the event's main venue — never your browser's local time, and never the reader's. A session at 09:00 in Vienna reads 09:00 to a manager in Chicago.

This has one practical consequence during setup: the main venue must have a timezone recorded before you can import a schedule, and reminder emails are scheduled against venue hours. Pick the venue early.