# Identity administration

> The three memberships that decide who can build and who can use a Helix app: organization role, workspace membership, and per-project access.

Access in Helix comes from three separate memberships: your role in the organization, the workspaces you belong to, and the projects whose published apps you have been granted. All three are managed inside Helix today. There is no identity provider to connect, and no code in a project decides who gets in.

## Organization membership

Everyone in your organization holds one of two roles, managed under Organization settings on the Members tab. That tab lists each person's name, email, role, status, and the number of workspaces they belong to.

| Role | What it means |
|---|---|
| Admin | Sees the Admin button and the org-wide [Admin console](/documentation/governance/admin-console/). Can set a project's access to Organization. |
| Contributor | Builds and deploys in the workspaces they belong to. No Admin console. |

**Org admins are hidden members of every workspace.** They do not appear in a workspace's member list, but they can reach every project in the organization and are included when a project's access is set to Workspace. When you count who can open a given app, add the admins.

Every role change is written to the [activity trail](/documentation/governance/audit-and-compliance/), so a promotion to Admin is visible after the fact.

:::note{title="Role capabilities are being confirmed"}
The precise list of actions each role can take is still being confirmed with engineering. What is documented above is the behavior visible in the shipped dashboard.
:::

## Workspace membership

Workspaces hold projects. Your workspace membership decides which projects you can open, build in, and deploy. The workspace switcher in the dashboard header lists the workspaces you belong to.

Organization settings separates the two cases:

- **Workspaces**: the ones you are a member of.
- **Other workspaces**: the ones in your organization that you are not a member of.

Workspace membership governs building. It does not, by itself, govern who can use a published app.

## Per-project app access

Each project has an Access Control tab that decides who can open its published app. Every app requires sign-in, so this setting is the whole of the access decision.

| Setting | Who can open the app |
|---|---|
| Workspace | Everyone in the project's workspace, plus org admins as hidden members. This is the default. |
| Only people invited | Only the people invited by name. |
| Organization | Everyone in your organization. Only an org admin can select this. |

Granting access and changing this setting are both recorded in the activity trail.

### Invitations reach the whole organization

Anyone in your organization can be invited to an app, including people who are not in the project's workspace and cannot see the project at all. They get the app, not the project.

This differs from Tray iPaaS, where access follows workspace scoping. If your existing controls assume that workspace boundaries contain who can reach what, that assumption does not carry over to Helix apps. Two practical consequences:

- A workspace is a boundary for building, not a boundary for app usage.
- Sharing decisions are made per project by whoever administers it, so review them rather than inferring them from workspace membership.

The [Admin console](/documentation/governance/admin-console/) lists the shared-with state of every project org-wide, which is the fastest way to audit this.

## What to check

There is no single access report. The three places to look are:

1. **Organization settings, Members**: who is in the organization and who holds Admin.
2. **Each project's Access Control tab**: who can open that app.
3. **The Admin console**: projects, shared-with state, authentications, and the activity trail, across every workspace.

:::note{title="Offboarding"}
The exact effect of removing or deactivating a member, and how quickly it revokes access to published apps, is being confirmed. Until it is, remove people from individual project access as well as from the organization when access must stop immediately.
:::

:::roadmap{title="SSO, IdP connections, and group sync"}
The platform design describes an identity layer that is not configurable today:

- Connecting an identity provider (Okta, Auth0, Azure AD, or Google Workspace) once at the organization level, with SSO for every deployed app.
- Auto-provisioning a Helix account the first time someone signs in through the IdP.
- Syncing IdP groups into Helix through SCIM, mapping a group to workspace membership or to the org admin role, so directory changes propagate automatically.
- Provisioning a dedicated IdP application per app, so the app gets its own tile, its own assignment workflow, and its own conditional-access policy.
- In-app roles declared in project configuration, with groups mapped to those roles by an admin. The project-side view of that design is in [identity and roles](/documentation/guides/identity-and-roles/).

Today, membership is managed in Helix one person at a time, and app access is set per project on the Access Control tab.
:::

---

Canonical: https://helix.tray.ai/documentation/governance/identity-administration/
Any link on this page is available as markdown by appending .md to its URL.
Full corpus: https://helix.tray.ai/documentation/llms-full.txt