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.
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.