Identity and organisations

One identity, several memberships

In the Cloud an email address identifies the person globally. They can be a member of several organisations — as a service provider looking after multiple customers, or as a person with a private and a professional context.

That is why the sign-in form has no field for the organisation: only email and password are entered. If the address belongs to exactly one organisation, you are in. If it belongs to several, a selection appears afterwards with name, plan and your own role.

The core remains untouched by this: it still knows only “user in a tenant”. The resolution from email to (tenant, user) hooks in via a hook that CE provides.

Viewing your own organisations

GET /api/v1/my/organisations

From this, the account page shows My organisations with plan and role — but only named (paid) organisations; the implicit free organisation stays hidden, because it is not a distinct entity from the user’s point of view.

Sharing across organisation boundaries

By default, a project share ends at the organisation boundary. Whoever needs external collaboration enables it explicitly:

GET  /api/v1/org/settings      # read state
POST /api/v1/org/settings      # set allowExternal (admin only)

In the interface the toggle is under Administration → Overview as Allow external collaborators on projects.

When it is active, project managers can invite a person from a different organisation to a project by email:

POST /api/v1/projects/{id}/share-external

Technically this creates a shadow account in the host organisation, bound to the global identity. The person keeps signing in with their usual address and finds the foreign organisation in their organisation selection. The data stays strictly separated — no access arises beyond the shared project.

Note

If allowExternal is off, a sharing attempt is rejected. The toggle is thus the single place where an organisation decides whether externals may come in at all.