Organizations

Organizations keep tenants apart: every org-scoped resource - flows, runs, devices, sites, secrets, variables, repositories, schedules - lives in exactly one organization, and what you see everywhere in the app is the active organization's data. Installed plugins and user accounts are platform-level and shared.

Switching organizations

The organization switcher sits in the sidebar. Your active organization determines every list and every action, and references across organizations are rejected by design. The one deliberate exception is the designated shared organization: while it is active, its resources are readable - read-only - from every other organization.

If you switch while you have one item open - a flow, a run, an edit form - you land on that item's list in the new organization, because the item itself stays in the organization you left.

Rows that came from the shared organization carry a Shared badge in every list. If you are a member of that organization, the badge is clickable and switches you into it - the shortest path from "I can see this but not change it" to the place where you can. Non-members see the badge as a plain label.

Roles are per organization

Your role - and therefore what you can do - is granted per organization: you can be an admin in one organization and a viewer in another. The permissions reference lists what each role allows.

Managing organizations

Under Settings → Organizations, platform admins can:

1. Create an organization with a name and slug.
2. Open an organization's detail to edit it.
3. Manage members: add users and assign their role in that organization.

Creating, editing, and deleting organizations is reserved for platform admins. An organization's own admins manage that organization's members and IdP mappings, but cannot create or edit organizations themselves.

Deployments that sign users in through an identity provider can map IdP groups to organizations and roles automatically - see IdP organization mapping.

History card

The detail page carries a History card listing the most recent audit log entries about this object: how long ago, what the action was, which fields changed, who did it, and a non-success outcome where there was one. A row opens the same entry dialog the audit log uses, and the card links into the log filtered to this object. It appears only for callers who may read the audit log, so an operator or org admin sees the page without it.

Related

• Audit log - events are recorded per organization, with platform-level events kept separate.
• Permissions reference - the role matrix.