Organizations

OpenFactory’s organization API stores organization memberships plus optional groups, units, and teams. It also supplies targets for sharing conversations/variants.

organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
    ├── unit members
    └── teams
        └── team members

This hierarchy is an authorization input. A role label is not proof that every build, VM, download, or deployment endpoint enforces the intended policy. See Roles and Permission Scope for the routes currently governed by each role.

Core objects

• Organization: top-level membership and administration boundary. A user can belong to multiple organizations.
• Group: named collection of organization members used as a share target; it is not an administrative hierarchy.
• Unit: department-like container with its own membership and stored workflow roles.
• Team: child of a unit with its own membership and stored workflow roles.

Users must be organization members before being added below it.

Safe setup sequence

1. Create the organization; the creator becomes an owner.
2. Add a second accountable owner before relying on the organization for durable operations.
3. Invite users to their exact email addresses and assign the lowest organization role required.
4. Add units or teams only when their scope changes an actual workflow.
5. Test one permitted action and one denied action using each representative role.
6. Review share and membership behavior after role removal and session refresh.

Invites expire and must be accepted by an account whose email matches the invitation. Do not transmit invite tokens in tickets or public logs.

Context and ownership

Organization selection can affect visible collaboration data, but individual resources still carry owner and share rules. Do not infer access to a private build or artifact merely because two users belong to the same organization. Use an explicit share where supported and test the download/VM action separately.

Isolation evidence

The organization and sharing routes perform membership checks and same-organization validation for their scoped operations. “Tenant isolation” is a broader system property and needs cross-tenant denied-path tests across conversations, builds, artifacts, VMs, APIs, caches, exports, and logs. Do not use the organization hierarchy alone as that evidence.

Administration safeguards

• Multiple owners are supported; the sole owner cannot leave.
• Only an owner can promote another owner or delete the organization.
• Deletion and membership removal can affect dependent access. Inventory shares, units, teams, active sessions, and owned resources first.
• Preserve an external audit record if your policy requires one; a current role listing is not a historical audit trail.

Continue with Sharing and Units and Teams.