Summary and recommendation
Launch Darkly user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
LaunchDarkly gives every app team four built-in roles - Reader, Writer, Admin, and Owner - available on all plans. Granular, environment-scoped permissions require custom roles, which are gated behind the Enterprise plan. Member management lives at Account settings → Members (https://app.launchdarkly.com/settings/members) and is accessible to any Admin or Owner.
Quick facts
| Admin console path | Account settings → Members (top-right avatar menu → Account settings → Members tab) |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Reader | View all resources across all projects and environments; cannot make any changes | Cannot create, edit, or delete flags, projects, environments, members, or any other resource | All plans (Developer, Foundation, Enterprise) | Counts as a billable seat on paid plans | Default role assigned to new members on some plan configurations; easy to over-provision if not reviewed |
| Writer | Create and edit flags, metrics, segments, and other resources; cannot manage account-level settings or members | Cannot invite or remove members, manage billing, create projects, or modify roles | All plans | Counts as a billable seat on paid plans | Writers can modify production flags if no environment-level restrictions are applied via custom roles |
| Admin | Full access to all resources including account settings, member management, billing, projects, environments, and flags | Cannot exceed permissions of the account Owner; on Enterprise, cannot modify Owner-only settings | All plans | Counts as a billable seat on paid plans | Multiple Admins can exist; there is no limit on Admin count, which can create governance risk |
| Owner | All Admin permissions plus exclusive access to billing management and the ability to delete the account | Cannot transfer ownership without explicit reassignment; only one Owner per account | All plans (exactly one per account) | Counts as a billable seat | Only one Owner allowed per account. If the Owner leaves, another Admin must be promoted to Owner before offboarding |
| No access | Cannot view or interact with any part of the LaunchDarkly account | All actions blocked | Enterprise (custom role assignment required to set no-access baseline) | Counts as a billable seat if the member record exists | Requires custom roles to implement; not a native built-in role selectable from the dropdown |
Permission model
- Model type: hybrid
- Description: LaunchDarkly uses four built-in roles (Reader, Writer, Admin, Owner) available on all plans. Enterprise plans add custom roles, which use a policy-based JSON syntax (allow/deny statements) scoped to specific resources, actions, projects, and environments. Custom roles can be assigned directly to members or to Teams. Teams can hold multiple custom roles and propagate them to all team members.
- Custom roles: Yes
- Custom roles plan: Enterprise
- Granularity: Resource-level and action-level via policy statements; can scope to specific projects, environments, flag keys, metrics, and segments. Supports effect (allow/deny), actions (e.g., updateOn, createFlag), and resource specifiers with wildcards.
How to add users
- Navigate to app.launchdarkly.com and sign in as Admin or Owner
- Click your account avatar (top-right) → Account settings
- Select the Members tab
- Click Invite members
- Enter one or more email addresses (comma-separated for multiple)
- Select a built-in role (Reader, Writer, Admin) or, on Enterprise, assign a custom role
- Click Send invitations
- Invitee receives an email invitation and must accept to activate their account
Required fields: Email address, Role (built-in or custom)
Watch out for:
- Invited members consume a seat immediately upon invitation acceptance, not at invite send time
- If SSO is enforced, members must log in via SSO; password-based login is disabled for those accounts
- On Enterprise with SCIM enabled, manually invited members may conflict with IdP-provisioned records if the same email is used
- Custom role assignment at invite time is only available on Enterprise; Foundation and Developer plans are limited to built-in roles
- There is no email domain allowlist to auto-approve invitations; each invite must be sent explicitly
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: LaunchDarkly allows permanent removal of a member from the account. Removal is immediate and the member loses all access. There is no 'deactivate' or 'suspend' state in the UI for manually managed accounts; the only options are active membership or removal. SCIM-provisioned accounts can be deprovisioned via the IdP, which removes the member from LaunchDarkly.
- Navigate to Account settings → Members tab (https://app.launchdarkly.com/settings/members)
- Locate the member using the search field
- Click the overflow menu (three dots) next to the member's name
- Select Remove member
- Confirm the removal in the dialog
| Data impact | Behavior |
|---|---|
| Owned records | Flags, segments, metrics, and other resources created by the removed member remain in the account and are not deleted. Audit log entries attributed to that member are preserved. |
| Shared content | All shared resources (flags, dashboards, segments) remain intact and accessible to other members with appropriate permissions. |
| Integrations | Any personal API access tokens created by the removed member are invalidated upon removal. Service tokens (account-level) are unaffected. |
| License freed | The seat is freed immediately upon removal, reducing the billable member count. |
Watch out for:
- The Owner role cannot be removed without first transferring ownership to another Admin
- Personal API tokens belonging to the removed member are immediately invalidated; any automation using those tokens will break
- If the member was the sole maintainer of a Team, the Team remains but has no maintainer; an Admin must reassign team ownership
- SCIM deprovision via IdP is the recommended path on Enterprise; manual removal and IdP deprovision can conflict if not coordinated
- There is no grace period or soft-delete; removal is immediate and irreversible from the UI
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Member seat | One human user account with a built-in or custom role; access to the LaunchDarkly web UI and personal API tokens | Included in plan; Foundation plan pricing is per service connection, not per seat. Enterprise pricing is custom and negotiated. |
| Service token / SDK key | Non-human API credential for SDK or integration use; does not consume a member seat | Included; not a separate seat charge |
- Where to check usage: Account settings → Members tab shows total member count. Billing details are under Account settings → Billing (https://app.launchdarkly.com/settings/billing). Member list can be filtered and sorted to identify last-active dates.
- How to identify unused seats: LaunchDarkly does not expose a native 'last login' column in the Members UI as of the current documentation. Admins can review the audit log (Account settings → Audit log) filtered by member to assess recent activity. SCIM-enabled accounts can rely on IdP last-login data to identify inactive users.
- Billing notes: Foundation plan is billed per service connection (SDK connection), not per seat. Enterprise is custom-priced. The free Developer plan includes up to 3 environments, 1 project, and 1,000 client-side MAUs. Member seat count is not the primary billing driver on Foundation; MAU and service connections are. On Enterprise, seat counts and MAU are both negotiated.
The cost of manual management
Without SCIM (Enterprise only), every joiner and leaver is a manual operation: locate the member, click the overflow menu, confirm removal. There is no CSV import for bulk invitations, so large onboarding waves mean sending individual invites one by one.
The Members UI exposes no native last-login column, so identifying inactive seats requires manually cross-referencing the audit log - a slow process that compounds as headcount grows.
Foundation plan customers are doubly constrained: no SCIM, no custom roles, and no team sync. Every app that needs environment-scoped access control must wait for an Enterprise upgrade before automation or fine-grained governance is possible.
What IT admins are saying
The most consistent friction point reported by practitioners is IdP lock-in for team sync: group-to-team mapping via SCIM works only with Okta.
Entra ID, OneLogin, and Google Workspace customers on Enterprise can provision and deprovision users automatically, but team membership must still be managed manually or via the REST API.
A second recurring complaint is the absence of a 'last login' field in the Members UI. Admins who need to reclaim unused seats must query the audit log and correlate activity by member - there is no one-click stale-user report.
Custom role complexity (JSON policy syntax with allow/deny statements) is also flagged as a steep learning curve for teams new to policy-based access control.
Common complaints:
- Team sync (automatic team membership via IdP group) is locked to Okta only; other IdPs (Entra ID, OneLogin, Google Workspace) do not support team sync even on Enterprise
- SCIM provisioning requires Enterprise plan, making automated user lifecycle management unavailable to Foundation customers
- Enabling both SAML SSO and SCIM for team assignment can cause conflicts if group-to-team mappings are not carefully coordinated
- No native 'last login' visibility in the Members UI makes it difficult to identify and remove inactive seats without querying the audit log manually
- No CSV import for bulk member invitations; large-scale onboarding without SCIM requires sending individual invitations
- Custom roles (needed for granular, environment-scoped permissions) are gated behind Enterprise, leaving Foundation customers with only four coarse built-in roles
- Only one Owner per account; if the Owner departs without transferring ownership, recovery requires contacting LaunchDarkly support
The decision
Choose manual management if your team is small, your IdP is not Okta, or you are on the Foundation plan - the built-in roles cover most read/write/admin splits without additional configuration. Upgrade to Enterprise and configure SCIM if you need automated provisioning, deprovision on offboarding, or environment-scoped custom roles enforced at scale.
If your IdP is Entra ID, Google Workspace, or OneLogin, factor in that team sync will not be available even on Enterprise. You will get automated user lifecycle management, but team membership assignments for every app will remain a manual or API-driven step.
Bottom line
LaunchDarkly's manual member management is straightforward for small teams but does not scale cleanly without Enterprise. The four built-in roles handle broad access splits, but any requirement for environment-level or flag-level permission boundaries demands custom roles - and therefore an Enterprise contract.
The absence of last-login visibility in the UI and the lack of bulk invite tooling mean that seat hygiene across every app requires deliberate audit-log discipline or an IdP-driven SCIM workflow to stay manageable.
Automate Launch Darkly workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
