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. 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, so a promotion to Admin is visible after the fact.
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 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:
- Organization settings, Members: who is in the organization and who holds Admin.
- Each project’s Access Control tab: who can open that app.
- The Admin console: projects, shared-with state, authentications, and the activity trail, across every workspace.