Summary and recommendation
InVision 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.
InVision's admin console gives Admins direct control over team membership from Account menu → Team Settings → Members. The permission model is role-based and fixed: Admin, Member, and Guest/Viewer. No custom roles exist, and project-level access is managed separately by adding users to individual projects.
SCIM provisioning is available, but only on the Enterprise plan and only after SSO is fully configured. For teams not on Enterprise, all user lifecycle management is manual - and like every app that lacks native activity reporting, the operational burden lands on whoever owns the Members list.
Quick facts
| Admin console path | Account menu (top-right avatar) → Team Settings → Members |
| 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 |
|---|---|---|---|---|---|
| Admin | Full account control: invite and remove members, manage billing, configure SSO/SCIM, manage team settings, access all projects within the team space. | Cannot be demoted by another Admin unless a separate Owner-level action is taken; cannot access projects they have not been explicitly added to on some plan tiers. | All plans | Counts as a paid seat on paid plans | Multiple Admins are permitted; there is no single 'Owner' role distinct from Admin in standard plans. On Enterprise, the account owner is the primary billing contact. |
| Member | Create and edit prototypes and design documents within projects they are added to; collaborate with other members; comment on shared content. | Cannot manage billing, invite new team members, configure SSO/SCIM, or access team-wide settings. | All plans | Counts as a paid seat on paid plans | Members must be explicitly added to individual projects to gain access; team membership alone does not grant access to all projects. |
| Guest / Viewer | View and comment on prototypes shared with them via a share link or direct invite; no editing rights. | Cannot create or edit content, manage projects, or access team settings. Cannot see other team members or projects they have not been invited to. | Available on paid plans; free plan limits guest access | Guests invited via share link do not consume a paid seat; guests added as team collaborators may consume a seat depending on plan | Guest access behavior differs between share-link guests (no seat consumed) and team-level guest invites. Confirm seat consumption with InVision billing before bulk-inviting guests. |
Permission model
- Model type: role-based
- Description: InVision uses a fixed set of team-level roles (Admin, Member, Guest/Viewer). Permissions are assigned at the role level and cannot be customized per user. Project-level access is controlled separately by adding or removing users from individual projects.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Team-level role assignment plus project-level membership; no field-level or resource-level permission customization available.
How to add users
- Log in as an Admin.
- Navigate to Account menu → Team Settings → Members.
- Click 'Invite people' or 'Add members'.
- Enter the email address(es) of the user(s) to invite.
- Select the role to assign (Admin or Member).
- Click 'Send invite'. The invitee receives an email to accept and join the team.
Required fields: Email address, Role (Admin or Member)
Watch out for:
- Invitations expire if not accepted; Admin must resend if the link lapses.
- Invited users consume a paid seat as soon as they accept the invitation, not when the invite is sent.
- On Free plan, team size is capped; inviting beyond the cap requires a plan upgrade.
- InVision has announced end-of-life for its core prototyping product; new invitations may be restricted depending on account migration status.
| 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: No
- Delete/deactivate behavior: InVision does not offer a hard-delete of a user account from the admin console. Admins can remove (deactivate) a member from the team, which revokes their access. The user's account itself persists with InVision; only team membership is terminated. Via SCIM on Enterprise, deprovisioning suspends the user's access automatically.
- Log in as an Admin.
- Navigate to Account menu → Team Settings → Members.
- Locate the user in the member list.
- Click the options menu (three dots or gear icon) next to the user's name.
- Select 'Remove from team' or 'Deactivate'.
- Confirm the action in the dialog prompt.
| Data impact | Behavior |
|---|---|
| Owned records | Projects and prototypes owned by the removed user remain in the team account and are not automatically deleted. Ownership transfer to another Admin or Member must be performed manually before removal if continuity is needed. |
| Shared content | Shared prototypes and documents the user contributed to remain accessible to other team members who have project access. |
| Integrations | Any personal API tokens or OAuth connections belonging to the removed user are invalidated upon removal. Integrations relying on that user's credentials will break. |
| License freed | The seat is freed immediately upon removal, making it available for a new invite on seat-limited plans. |
Watch out for:
- Ownership of projects is not automatically transferred; orphaned projects may become inaccessible to the team if the owner is removed without prior transfer.
- Admins should audit and reassign project ownership before removing a user.
- SCIM-based deprovisioning on Enterprise suspends access but does not transfer project ownership automatically.
- Removed users can still log in to their personal InVision account; they simply lose access to the team workspace.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Full Member seat | Create, edit, and collaborate on prototypes and design documents; full team workspace access based on role. | Included in plan seat count; per-seat pricing approximately $0 (Free) to $7.95/month on self-serve plans; Enterprise negotiated annually. |
| Guest / Viewer (share-link) | View and comment on specific shared prototypes via link; no team workspace access. | No seat consumed; unlimited share-link viewers on paid plans. |
- Where to check usage: Account menu → Team Settings → Members (shows current member count and seat usage); Billing section shows plan seat limit and current consumption.
- How to identify unused seats: InVision does not provide a native 'last active' or 'last login' report in the standard admin console. Admins must manually review the Members list and cross-reference with project activity. Enterprise accounts with SCIM/SSO may be able to use IdP last-login data to identify inactive users.
- Billing notes: Seats are billed based on accepted team members. Pending invitations do not consume seats until accepted. Enterprise contracts are annual and seat counts are negotiated upfront; mid-term seat reductions typically require contract renegotiation. InVision has announced end-of-life for its core product line; new Enterprise contracts may no longer be available.
The cost of manual management
InVision provides no native last-login or activity report in the standard admin console. Identifying inactive seats requires manually cross-referencing the Members list against project activity - a time-consuming process with no automation path outside of Enterprise SCIM with IdP last-login data.
Enterprise contracts are negotiated annually with seat counts fixed upfront. Mid-term seat reductions typically require contract renegotiation, meaning unused seats carry real cost until renewal. Guest/viewer seat consumption rules add further ambiguity: share-link guests consume no seat, but team-invited guests may, and the distinction is not clearly surfaced in the UI.
Project ownership is not automatically transferred when a member is removed. Orphaned projects can become inaccessible to the team, requiring manual audits before every offboarding.
What IT admins are saying
Admins consistently flag three pain points in community discussions. First, removing a team member does not trigger any ownership transfer, leaving orphaned projects that are hard to recover.
Second, the absence of a last-login report makes license audits manual and error-prone. Third, guest seat consumption rules are reported as inconsistent and unclear between share-link and team-invited guests.
Additional friction: invitation emails are frequently caught by spam filters, requiring manual follow-up. Enterprise customers also note that SCIM deprovisioning handles access suspension but leaves project ownership reassignment as a separate manual step.
Common complaints:
- Users report that removing a team member does not automatically transfer project ownership, leading to orphaned projects that are difficult to recover.
- Admins note there is no built-in last-login or activity report, making it hard to identify inactive seats for cost optimization.
- Community members have flagged that guest/viewer seat consumption rules are unclear and inconsistent between share-link guests and team-invited guests.
- Users report confusion about InVision's product end-of-life announcements and how they affect the ability to add new users or renew seats.
- Some admins report that invitation emails are frequently caught by spam filters, requiring manual follow-up with invitees.
- Enterprise customers have noted that SCIM deprovisioning suspends access but does not handle project ownership reassignment, requiring a separate manual workflow.
The decision
InVision is mid-transition: the company has announced end-of-life for its core prototyping product line and is integrating with Miro. This directly affects whether new Enterprise contracts are available and whether SCIM provisioning remains fully supported for your specific account version (V7 vs. Enterprise).
Like every app undergoing a platform migration, the safest move is to confirm your product version and migration status with InVision before committing to any automation build.
For teams already on Enterprise with SSO active, SCIM via Okta, Entra ID, or OneLogin is the only viable path to automated provisioning. For all other tiers, manual administration through the Members console is the only option.
Bottom line
InVision's manual admin workflow is straightforward for small teams but does not scale cleanly: no activity reporting, no automatic ownership transfer on removal, and ambiguous guest seat rules create recurring operational overhead.
The Enterprise SCIM path resolves provisioning and deprovisioning automation, but requires SSO as a hard prerequisite and is subject to the platform's ongoing end-of-life transition.
Any team managing InVision seats at scale should validate their account's migration status and SCIM availability before building processes around it.
Automate InVision 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.
