Workspaces and Tenants

Ema's platform uses a multi-tenant architecture to provide secure, isolated environments for partners and their customers. A workspace (also called a tenant) is the fundamental unit of data isolation on the Ema platform.

Each workspace has its own:

Users and roles -- Managed independently; access to other workspaces must be explicitly granted.
AI Employees -- Operate within that workspace's data boundaries.
Data, workflows, and configurations -- Fully isolated from every other workspace.

Workspace-Level Roles

Workspace roles govern what a user can do across the workspace as a whole.

Role	Workspace Management	Build Access	Default AI Employee Role
Admin	Can invite users, view metrics	Can build new AI Employees	AI Employee Admin
Manager	Can invite users, view metrics	No access	AI Employee Manager
Builder	No privileges	Can build; receives Admin role for AI Employees they create	No access (unless invited)
Guest	No privileges	No access	No access (unless invited)

AI Employee-Level Roles

AI Employee roles govern what a user can do within a specific AI Employee. All users can use the AI Employee; these roles control management privileges.

Role	AI Employee Management	Workflow Access	Audit Logs
Admin	Can invite users, view metrics	Can edit	Can view
Manager	Can invite users, view metrics	Can view (read-only)	Can view
Project User	No privileges	No access	No access

A user's workspace role determines their default AI Employee role. However, users can be granted different roles for specific AI Employees independently. For example, a user with the Guest workspace role could be given the Builder role for a particular AI Employee.

Parent-Child Workspace Relationships

Ema supports hierarchical workspace relationships where a parent workspace can have one or more child workspaces.

Key Rules

Capability	Direction	Details
User Access	Downward	Parent users can access child workspaces, but only on explicit invitation. Access is never automatic.
Template Sharing	Downward	Parent workspaces can share AI Employee templates to child workspaces.
Metrics	Upward	Aggregated metrics roll up from child to parent. No PII or log data moves upward. -- metrics rollup may still be in development.
Data and Logs	None	No data flows between workspaces in either direction.

Constraints

A child workspace can only have one parent.
Workspace hierarchies can be multiple levels deep -- child workspaces can have their own children.
Only a parent workspace's users can be invited to its direct child workspaces. You cannot skip levels (a grandparent user must first be added to the parent, then to the child).

Workspace Management Models

Partners can organize their customer workspaces using one of four models.

Model 1: Standard (Recommended)

Each customer gets its own workspace with full data isolation. Best when:

Each customer requires full data isolation.
Customers may log into the Ema platform directly.
You need clear boundaries between customer environments.

Model 2: Multiple Workspaces for the Same Company

Internal separation by region, department, or business unit.

Limitation: Every workspace requires a unique domain. Additional workspaces for the same company must use a non-standard/placeholder domain (e.g., company-us.co instead of company.com).

Model 3: Single Workspace Across Multiple Companies

All customers operate within the partner's single workspace. Best for:

Customers that interact via embedded chatbots, SDKs, or APIs (not the Ema UI).
Small customers or lightweight use cases.
Scenarios where the partner fully manages all AI Employees.

Data separation is achieved at the AI Employee level (data does not flow between AI Employees unless explicitly connected) and at runtime (individual workflow executions are isolated).

Model 4: Data Localization Across Geographies

For data residency and compliance requirements, separate Ema environments must be provisioned in each target region.

Sub-workspaces do NOT solve data localization. All workspaces within the same environment share the same underlying infrastructure. True data localization requires a completely separate Ema environment in the target geography.

Separate environments have no cross-environment template sharing, metrics aggregation, or user access.

Choosing the Right Model

Criteria	Standard	Multi-Workspace	Single Workspace	Geo-Localized
Data isolation	Full	Full	AIE/Runtime	Full (per env)
Customer logs into UI	Yes	Yes	No	Yes
Setup complexity	Low	Medium	Lowest	Highest
Best customer size	Any	Large (internal sep.)	Small/Embedded	Any (global)

Decision guide:

Does the customer log into the Ema UI? If no and no dedicated isolation is needed, use Model 3.
If yes, does the same company need internal separation (region/department)? If no, use Model 1.
If internal separation is needed, are there data residency requirements? If no, use Model 2. If yes, use Model 4.

Switching Workspaces

Current state: When a partner user needs access to a child workspace, they must use an email alias (e.g., [email protected]) and log out/log in to switch between workspaces.

Future state (Workspace Switcher): An upcoming update will eliminate alias-based access:

Same email/user ID works across all workspaces.
Workspace switcher dropdown in the UI -- no log out/log in required.
Access to child workspaces still requires explicit invitation.

-- The workspace switcher feature may have shipped since this documentation was drafted. Check the current release notes for availability.

FAQs

What is the smallest unit of data isolation? The workspace. AI Employees also have data separation, and individual workflow executions have runtime isolation.

Do child workspaces inherit users from the parent? No. Users must be explicitly invited to each child workspace.

Can templates be shared upward from child to parent? No. Templates can only be shared downward.

How do I prevent a customer from building AI Employees? Assign the customer's users as Manager or Guest (no build access).

Next: GWE Overview