How organizations, workspaces, and environments fit together, and how to manage who can do what.
Xenia's structure is three levels deep, and everything about access and isolation follows from it.
Organization
└── Workspace
└── EnvironmentAn organization is your company. It owns billing, sign-in settings, and the list of workspaces. A workspace is a separate space with its own data, members, and connectors, so one company can run several brands or regions side by side. An environment sits inside a workspace, such as Development and Production, and has its own connectors and its own data.
Nothing crosses a workspace boundary. Nothing crosses an environment boundary either, which is why a connector, a saved step setting, or an access token always belongs to one environment.
Choosing your context
The context switcher in the top bar selects the workspace and environment you are working in. Switching resets the app's state and reloads everything in the new context, so the journeys, connectors, and audiences you see always belong to the context shown.
Most confusing problems come down to being in the wrong place: a connector added in Development, a journey published in Production. If something works in one place and not another, compare the two first.
Managing workspaces and environments
Workspace Admin is where organization administrators provision and manage the structure. From one place you can create and edit workspaces, change their status, and manage environments underneath them.
Workspace statuses:
Environments are Active, Disabled, or Archived in the same way.
A new environment starts empty. Connectors, saved step settings, and journeys do not move between environments on their own, so going live with something you built in testing means setting up what it depends on in the live environment too.
Roles
There is a detailed list of job titles to pick from when you invite someone, and each one behaves as one of four levels of access:
The sidebar only shows what your level can use, so people are not looking at pages they cannot act on.
In practice:
- Admin creates workspaces and environments, manages members, sets up sign-in, and handles billing.
- Manager builds and approves work, and manages members.
- Marketer builds audiences, content, and journeys, and submits them for approval.
- Developer sets up connectors, tests journeys in simulation, and manages access tokens.
Inviting people
Members and Access lists current members, their scope, and their role, alongside pending invitations and their expiry.
Invite
Send an invitation scoped to the workspace, and the environment where that applies.
Assign a role
Pick the job title that matches what the person does. It sets one of the four access levels above.
Manage over time
Change a member's role, grant or revoke access for a scope, or revoke an invitation that has not been accepted.
Invitations expire, and the pending list shows when. An expired invite needs to be sent again rather than extended.
SSO and authentication
Organization administrators can configure enterprise identity providers under SSO and Auth, so your team signs in with your existing identity provider and access follows your directory rather than a separate user list.
API tokens
API Tokens is where you create tokens so your own site or app can talk to Xenia. Each token belongs to one workspace and one environment.
A token is shown only when you create it, and Xenia keeps no copy it can show you again, so store it somewhere safe. The page lists your tokens with who created them and when they expire, and lets you revoke any of them. A revoked token stops working within about a minute.
See Personalization API for what your developers do with one.
Related
- Connectors, which are configured per environment
- Subscriptions for plans and usage