User membership reference
This page is a complete reference for how users join organizations in Port. It covers every path a user can take to become a member — SSO login, SCIM provisioning, invitations, and manual API calls — along with how member statuses work and what to expect in common edge cases.
Prerequisites
- Most settings described on this page require account admin or organization admin permissions.
- The Automatic user access toggle is available to account admins on paid plans only.
How users join an organization
There are several ways a user can be added to an organization.
The table below summarizes each path, what triggers it, and the initial status the user receives.
| How the user is added | When it happens | Condition | Initial status |
|---|---|---|---|
| Company SSO login | User logs in via a company-wide SSO connection | Automatic user access is enabled on the org | Active |
| Org-level SSO login | User logs in via an SSO connection scoped to one specific org | Always — all users on that connection are added unconditionally | Active |
| SCIM provisioning | A user is created or updated in your identity provider | Automatic user access is enabled on the org | Staged (becomes Active on first SSO login) |
| Admin invitation | An org admin explicitly invites the user | — | Invited (becomes Active on first login) |
| API — invite user | A POST /users/invite API call | — | Invited (becomes Active on first login) |
| Users & Teams blueprint | A user entity is created in the Users system blueprint | — | Staged by default; Invited if status: INVITED is set explicitly on the entity |
| Company onboarding | First-time account setup | — | Active |
None of the flows above will change a Disabled membership to any other status. If a user has a disabled membership in an org, it stays disabled regardless of how they log in or how they were provisioned. Re-enabling always requires an explicit admin action.
The "Automatic user access" toggle
Automatic user access is a per-organization setting (under Organization settings → Settings) that controls whether users who authenticate via your company-wide SSO connection are automatically added to that org.
- Enabled: any user signing in via your company's SSO connection is added to the org automatically. If SCIM is active on your account, SCIM-provisioned users are also added to the org as Staged — before they ever log in.
- Disabled: only users who have been explicitly invited appear in the org.
This is useful when you have multiple environments (e.g. dev and prod) and want to grant broad access to dev while keeping prod invite-only.
When multiple orgs have Automatic user access enabled, Port routes new SSO users to the oldest org by creation date — which may not be the one you want. You can explicitly designate one org as the default landing destination. See Default login organization for setup steps.
Note that Automatic user access applies only when your SSO connection is set up at the company level. If an SSO connection is scoped to a single org (org-level SSO), every user on that connection is added to the org unconditionally — the toggle is not consulted. See Org-level SSO below for more detail.
Automatic user access is not available on the Free plan. It can only be configured by account admins.
Member statuses
Every org membership has one of four statuses. The table below explains what each status means and how it changes.
| Status | What it means | Can log in? | Has API access? | How it becomes Active |
|---|---|---|---|---|
| Active | Full member — all org permissions apply | Yes | Yes | N/A — already active |
| Invited | User was added explicitly but hasn't logged in yet | Yes | Yes | On first successful login |
| Staged | User was provisioned via SCIM or blueprint entity creation before their first login | Yes | No | On first SSO login |
| Disabled | Membership was disabled by an admin | Yes (marked as disabled) | No | Never auto-promoted; must be manually re-enabled |
Both Staged and Invited users become Active on their first login. The difference is origin: Staged comes from SCIM provisioning or Users & Teams blueprint entity creation (default). Invited comes from an explicit admin action, API call, or a blueprint entity created with status: INVITED.
Note that transitions from Active back to Invited or Staged are blocked — membership status only moves forward unless an admin explicitly disables it.
Edge cases
Disabled users and new organizations
When you disable a user's membership in an org, their access to that specific org is revoked. A few things to keep in mind:
- Disabled users can still authenticate — they can complete the sign-in flow, but their session token carries a disabled flag that blocks access within Port.
- API token creation is blocked for users who are disabled in all of their orgs.
- Disabled memberships are never auto-promoted back to Active — re-enabling always requires a manual admin action.
Why a disabled user can still be added to a new org as Active:
Disabling a membership in one org does not create a company-wide block on that user. It applies only to that specific org membership. Port's auto-join logic runs independently per org: when a disabled user logs in via company SSO, Port checks each org separately. If the user is not yet a member of an accessible org (one with Automatic user access enabled), they are added to that new org as Active — just like any other new user would be.
This is intentional behavior. You may want to restrict someone from a production org while still granting access to a sandbox org. To block a user company-wide, you need to either disable them in every org they belong to, or remove them from all orgs entirely.
Non-SSO logins and automatic user access
The auto-join check runs only when a user signs in via SSO. Other login methods bypass it entirely:
| Login method | Auto-join runs? |
|---|---|
| Company SSO | Yes |
| Org-level SSO | N/A — users are always added unconditionally |
| Username / password | No |
| Social login (Google, GitHub, etc.) | No |
| SCIM provisioning | Yes — independently of any login |
SCIM is the one exception: it checks Automatic user access at provisioning time, without waiting for the user to log in. A SCIM-provisioned user is added to all accessible orgs as Staged immediately when they are created or updated in your IdP. Their first SSO login then promotes them to Active.
SCIM-managed users on subsequent logins
If a user was provisioned via SCIM, their profile (name, email, etc.) is owned by your identity provider — Port will not override profile attributes on login. However, org membership assignment still runs on every login: if new orgs have become accessible since the user last signed in, they are added to those orgs automatically.
Org-level SSO — Automatic user access is not relevant
When an SSO connection is scoped to a single org rather than the whole company, Automatic user access plays no role. Every user on that connection is always added to the org on login. The multi-org auto-join logic (which checks the toggle across all orgs in the company) does not run for org-level SSO connections.
Users & Teams blueprint — controlling the initial status
When a user entity is created in the Users & Teams blueprint, the initial membership status depends on the status property set on the entity:
status property on the entity | Initial membership status | Invite email sent? |
|---|---|---|
| Not set (default) | Staged | No |
STAGED | Staged | No |
DISABLED | Disabled | No |
INVITED or ACTIVE | Invited | Yes |
This means that creating users via a self-service action or automation that targets the Users blueprint will produce Staged users by default — no invite email is sent, and they become Active on their first SSO login.
Quick reference
| User type | Login method | Automatic user access | Resulting orgs and status |
|---|---|---|---|
| New company user — first login | Company SSO | Enabled | Added to every org with the toggle on → Active |
| New company user — first login | Company SSO | Disabled | No orgs added automatically |
| SCIM-provisioned (no login yet) | SCIM only | Enabled | Added to every org with the toggle on → Staged |
| SCIM-provisioned — first login | Company SSO | Enabled | Staged → Active; any new accessible orgs are also added |
| Invited user | Any | N/A | Specific invited org → Invited → Active on first login |
| Org-level SSO user | Org SSO | N/A (ignored) | That org only → Active |
| Disabled user — logs in via company SSO | Company SSO | Enabled | Existing disabled memberships stay Disabled; added to new accessible orgs as Active |
| Username/password or social login | Non-SSO | Any | No auto-join; existing memberships unchanged |
For related configuration, see:
- Multiple organization membership — how to create orgs, enable Automatic user access, and set a default login org.
- SCIM provisioning — how to connect your identity provider and configure SCIM.
- Manage users and teams — how to invite users, manage roles, and disable memberships.