Figma User Management Guide

• Model type: role-based
• Description: Figma uses a layered role-based permission model. Roles exist at three levels: organization (Org Admin), team (Team Admin, Member, Viewer), and file/project (Editor, Viewer, Viewer-Restricted). Org-level roles govern administrative access; team and file roles govern content access. Permissions cascade downward but can be restricted at lower levels.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Three levels: organization, team, and file/project. No custom role creation. Admins can control default seat type assigned to new members via org settings on Organization and Enterprise plans.

1. Navigate to figma.com and open the Admin panel for your organization (Admin → Members).
2. Click 'Invite members' or 'Add members'.
3. Enter the email address(es) of the user(s) to invite.
4. Select the role to assign: Editor or Viewer (Viewer-Restricted available on Org/Enterprise).
5. Optionally assign the user to one or more teams during the invite flow.
6. Click 'Send invite'. The user receives an email invitation and must accept to join.
7. On Organization/Enterprise plans, if the invited user accepts and is assigned an Editor role, a paid seat is consumed immediately.

Required fields: Email address, Role (Editor or Viewer)

Watch out for:

• Inviting a user as an Editor on Organization or Enterprise plans immediately allocates a paid seat upon acceptance.
• On Enterprise plans with SCIM enabled, manual invitations may conflict with IdP-provisioned accounts; it is recommended to provision exclusively via SCIM to avoid duplicate accounts.
• Users invited to a file directly (not via the admin console) can also consume Editor seats if granted edit permissions, bypassing the admin invite flow.
• Domain verification (domain capture) on Organization/Enterprise plans can automatically add users with matching email domains to the org when they sign up, which may create unexpected seat consumption.
• Pending invitations still count toward seat limits on some plan configurations until the invite expires or is revoked.

• Can delete users: Verify in tenant
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Navigate to figma.com → Admin → Members.
2. Locate the member using search or filters.
3. Click the '...' (more options) menu next to the member's name.
4. Select 'Remove from organization' (or 'Deactivate' if using SCIM-managed accounts).
5. Confirm the removal in the dialog. The user is immediately removed from the org and loses access to org teams, projects, and files.
6. For SCIM-managed users: deprovision the user in your IdP; the SCIM integration will automatically deactivate the user in Figma.

Watch out for:

• Drafts owned by a removed user are not automatically reassigned; on non-Enterprise plans, this content may become inaccessible without manual intervention before removal.
• On Enterprise plans, admins can use the 'Content management' admin tools to locate and transfer files before removing a user.
• Removing a user does not cancel any active file-sharing links they created; those links may remain functional until explicitly revoked.
• If the user is re-invited after removal, they rejoin as a new member and a new seat is allocated; historical activity may not be fully restored.
• SCIM deprovisioning is the recommended method for Enterprise orgs to ensure consistent deactivation across SSO and Figma simultaneously.

• Where to check usage: figma.com → Admin → Members (shows all members with their assigned roles and seat types); Admin → Billing (shows total seat count and cost).
• How to identify unused seats: Figma does not natively surface a 'last active' or 'last login' date in the standard admin Members view for all plans. Enterprise plans with audit log access can use activity logs to identify inactive Editor seats. Third-party IdP activity reports or SCIM audit logs can supplement this. Admins can manually review the member list and downgrade inactive Editors to Viewer to free seats.
• Billing notes: Organization and Enterprise plans are billed annually per Editor seat. Viewer seats are free and unlimited. Adding an Editor mid-cycle is prorated. Removing an Editor mid-cycle does not generate a refund on annual plans; the seat count adjusts at the next renewal. As of early 2025, Figma introduced billing model changes affecting how seats are counted and managed, particularly for orgs migrating between plans or using SCIM. Admins should review the updated billing documentation before making bulk seat changes.

Without automated provisioning, repetitive admin work accumulates fast: manually inviting users, tracking seat types, and hunting down inactive Editor seats with no native last-active date visible in the Members panel on non-Enterprise plans.

Figma's billing model compounds this - Editor seats are consumed on invite acceptance, and a file owner sharing with edit permissions can silently allocate a paid seat without going through the admin console. On annual plans, removing an Editor mid-cycle does not generate a refund; the seat cost carries to renewal.

Bulk seat changes around plan migrations carry real financial risk without a clear audit trail, particularly given Figma's early-2025 billing model updates.

Admins on community forums flagged Figma's 2025 billing changes as a source of unexpected cost increases, particularly for organizations adjusting SCIM configurations or migrating between plans.

The absence of a native last-active date in the Members panel on non-Enterprise plans is a recurring friction point - identifying unused Editor seats requires either Enterprise audit log access or manual review.

Viewer-to-Editor seat escalation without explicit admin approval is another common complaint: any file owner can share with edit permissions and trigger a paid seat assignment. The Organization vs.

Enterprise feature split - especially around full SCIM seat management and multiple IdP support - also generates confusion at the point of plan selection.

Common complaints:

• Billing model changes in 2025 (including seat count methodology updates) caused confusion and unexpected cost increases for some Organization plan customers migrating or adjusting SCIM configurations.
• No native 'last active' date visible in the admin Members panel on non-Enterprise plans, making it difficult to identify and reclaim unused Editor seats without audit log access.
• Viewer-to-Editor seat escalation can happen without explicit admin approval when a file owner shares a file with edit permissions, leading to unplanned seat consumption.
• Drafts owned by removed users are not automatically transferred on non-Enterprise plans, creating content loss risk.
• Organization vs Enterprise feature differentiation (e.g., full SCIM seat management, multiple IdP support via Governance+, audit logs) is not always clearly communicated, leading to plan selection confusion.
• Multiple IdP support (Governance+ feature) is only available on Enterprise, which surprises admins who assumed it was included in Organization.
• Pending invitations consuming seats before acceptance has been reported as unexpected behavior by admins managing large organizations.
• No bulk CSV import for users; large-scale manual onboarding without SCIM requires individual email invitations.

When evaluating every app in your design and collaboration stack, Figma's plan boundaries matter: choose Organization if you need basic SCIM provisioning and SAML SSO and can accept that full SCIM seat management and multiple IdP support are gated to Enterprise.

Move to Enterprise if your org requires complete SCIM-driven seat control, audit log access for inactive seat identification, or content management tools to transfer files before removing users. If you are on a non-Enterprise plan, establish a file-sharing policy to prevent unintended Editor seat escalation and plan for manual seat audits.

Review Figma's updated billing documentation before making bulk seat changes given the March 2025 billing model migration.

Bottom line

Figma's permission model is capable but layered: org, team, and file roles each carry independent access implications, and paid Editor seats can be allocated outside the admin invite flow.

Manual administration is workable at small scale but becomes error-prone as headcount grows - seat escalation, missing last-active data, and non-refundable annual seat costs all create compounding overhead.

Organizations on Enterprise have the tooling (audit logs, SCIM seat management, content transfer) to manage this systematically; those on Organization plan should build compensating processes around file-sharing governance and regular manual seat reviews.