Platform model
ema is organized around two core containers: organizations and projects. Understanding how they nest and why data stays separate between them makes the rest of the platform easier to reason about.
Organizations
An organization is your company, association, or team's home in ema. It owns:
- the users who belong to your team
- org-wide configuration (default currency, branding, integrations)
- programs and settings that can span multiple events (for example, a CPD program that applies to several years of conferences)
- contracts and billing
You typically have one organization. Large groups with multiple brands or divisions sometimes have more than one.
Projects
A project is a single event or initiative inside your organization. Registration, the conference program, exhibitors, financials, tasks, and documents all live inside a project and are scoped to that project only.
Each project has its own:
- settings and configuration
- registration catalog
- program and schedule
- financial accounts and orders
- team members and their project roles
You might have a project for "Annual Conference 2026", another for "Members Workshop Q3 2026", and another for a trade show. They share your organization's users and branding defaults but otherwise operate independently.
Data isolation
Your ema instance has its own isolated database, not shared with any other ema customer — your registrants, financial records, documents, and event content are never visible to another customer.
Within your instance you can have more than one organization (agencies and PCOs have one for themselves plus one per client). These organizations share the instance but are separated by access control: a user only sees the organizations and projects their roles grant them, and configuration in one organization does not affect another. See PCO and agency model for how this works when you run events for external clients.
Surfaces — where you land
ema is one product with several distinct places you can end up, depending on who you are and what you're doing. Knowing which one you're in explains a lot of otherwise-confusing behaviour — why a screen looks different for a client, or why a feature "isn't there."
| Surface | Sign-in | Who lands here | What it's for |
|---|---|---|---|
Admin (/admin) | Yes | Your own staff, and client organisation contacts | Running the event: full configuration and management for your team, a scoped read-mostly view for clients. One app — what you see depends on your role, not a different login. |
Me (/me) | Yes | Every signed-in person | Personal self-service: your own registrations, tasks, approvals, documents — plus role areas for exhibitors, speakers, and reviewers. Same app and login as Admin; it's a different area of the same sign-in. |
| Public web | No | Anyone with the link | Registration forms, floor plans, the knowledge base, and public event pages. No account needed. |
| Onsite | Paired, not logged in | Your on-site delivery team, physically at the venue | Room control, prep, projector, and confidence-monitor views running on venue hardware. A device is paired to a specific room or role with a one-time key — it isn't reached by signing in from a browser. |
| Superadmin | Yes, internal only | ema's own platform team | Cross-tenant platform administration. It exists to operate the product, not to run your events — you and your team will never be granted access to it, and nothing in your day-to-day work depends on it. |
A check-in kiosk or ePoster kiosk you set up for attendees is an unattended, device-authenticated instance of Public web — not part of Onsite. Onsite is specifically the paired, room-scoped appliance surface your production team runs, configured from the Onsite module in Admin.
Exhibitors, speakers, and reviewers never get a separate portal or login of their own — their area lives inside Me, gated by the access they've been given for that project.
What this means for day-to-day work
- Configure org-wide defaults once (currency, branding, integrations) and let projects inherit them.
- Create a new project for each event rather than reusing one — separate project records keep historical data clean.
- Assign team members to the projects they actually work on, not to the organization globally, to keep access narrow.
Manage your organization's details, team members, and org-level settings.
Set up project roles to control what each team member can do inside a project.
Modules control which feature areas are active inside each project.
How tenant, organisation, and project roles combine to decide what each person can do on each surface.
Pair devices and configure the Onsite surface for a venue.