Summary and recommendation
Miro 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.
Miro's admin controls are split across two scopes: company-level and team-level. Company Admins manage billing, SSO, SCIM, and all users across every app team from Company Settings → Users tab. Team Admins operate within a single team only and cannot touch company-wide settings.
The permission model has three fixed tiers - company role, team role, and per-board access (Editor, Commenter, Viewer). There are no custom role definitions; every role's permissions are predetermined by Miro.
Quick facts
| Admin console path | miro.com → Profile avatar → Company settings → Users 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 |
|---|---|---|---|---|---|
| Company Admin | Full administrative control over the company account: manage billing, configure SSO/SCIM, create/delete teams, manage all users across all teams, set company-wide security policies, access audit logs (Enterprise). | Cannot access board content they have not been explicitly invited to unless they are also a Team Admin or member of that team. | All paid plans; role must be assigned by another Company Admin | Counts as a paid Full Member seat | Only Company Admins can configure SCIM and SAML SSO. There can be multiple Company Admins but at least one must exist at all times. |
| Team Admin | Manage members within a specific team: invite/remove team members, change team member roles, manage team settings and board permissions within that team. | Cannot manage billing, configure SSO/SCIM, or administer other teams they are not admin of. | All plans | Counts as a paid Full Member seat | Team Admin scope is limited to the team(s) they administer; they do not have company-wide visibility. |
| Full Member | Create and edit boards within teams they belong to, invite guests to specific boards, collaborate in real time. | Cannot manage team settings, billing, or other users' roles. | All plans | Counts as a paid licensed seat on Starter, Business, and Enterprise plans | On the Free plan, Full Members are unlimited but the team is limited to 3 editable boards. |
| Guest (External User) | Access only the specific boards they have been explicitly invited to; can view or edit depending on board-level permission granted. | Cannot see other boards, team members list, or any team-level content beyond their invited boards. | Business and Enterprise plans; not available on Free or Starter | Does not consume a paid Full Member seat; guests are free up to plan limits | Guest access must be enabled by a Company or Team Admin. On Business, guest limits may apply. Guests authenticate with their own email and are not provisioned via SCIM. |
| Viewer (Board-level) | Read-only access to a specific board; can comment if comment permission is granted. | Cannot edit board content, create sticky notes, or modify any objects. | All plans (board-level role, not a team-level role) | Does not consume a paid seat when set as a non-member viewer via a shareable link; consumes a seat if the viewer is a team member | Viewer is a board-level permission, not a team membership role. Shareable view-only links do not require the viewer to have a Miro account. |
Permission model
- Model type: role-based
- Description: Miro uses a two-tier role-based model: company-level roles (Company Admin, Full Member) and team-level roles (Team Admin, Member). Board-level access is layered on top and can be set to Editor, Commenter, or Viewer per board. There are no custom role definitions; permissions are fixed per role.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Three levels: company-wide role, team-level role, and per-board access level. Board-level permissions can be set individually per user or via shareable link settings.
How to add users
- Navigate to miro.com and sign in as a Company Admin or Team Admin.
- Go to Company Settings → Users tab (Company Admin) or open the specific Team → Team Settings → Members (Team Admin).
- Click 'Invite members'.
- Enter one or more email addresses in the invite field (comma-separated for multiple).
- Select the role to assign: Full Member or Team Admin.
- Click 'Send invite'. Invitees receive an email with a join link.
- Invited users appear as 'Pending' until they accept the invitation.
Required fields: Email address of the invitee, Role selection (Full Member or Team Admin)
Watch out for:
- Pending invitations still consume a paid seat on Starter and Business plans once the invite is sent.
- If SSO is enforced, invited users must authenticate via the configured IdP; they cannot set a password.
- On the Free plan, there is no seat limit but only 3 editable boards exist for the whole team.
- Company Admins can invite users at the company level; Team Admins can only invite to their specific team.
- Users invited to a team are not automatically added to all boards; board access must be granted separately or via team board defaults.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Company Settings → Users → Invite members → 'Import CSV' option; CSV must contain email addresses (and optionally display names) |
| Domain whitelisting | Yes | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Miro does not permanently delete user accounts from the admin console. Admins can only deactivate (suspend) a user. Deactivated users cannot log in and do not consume a paid seat, but their account record and all content they created remain intact. Permanent account deletion requires the user themselves to submit a data deletion request under GDPR/privacy rights, or for Enterprise customers to contact Miro support.
- Sign in as a Company Admin.
- Navigate to Company Settings → Users tab.
- Locate the user by name or email using the search field.
- Click the three-dot (⋯) menu next to the user's name.
- Select 'Deactivate user'.
- Confirm the deactivation in the dialog. The user is immediately blocked from logging in.
| Data impact | Behavior |
|---|---|
| Owned records | All boards and content created by the deactivated user remain in the team and are still accessible to other team members who had access. Ownership of boards is not automatically transferred. |
| Shared content | Boards the deactivated user was a member of remain visible and editable by other members. The deactivated user's contributions (sticky notes, shapes, comments) are preserved with their name attributed. |
| Integrations | Any personal OAuth integrations (e.g., Jira, Asana tokens) connected under the deactivated user's account will stop functioning for automations tied to that user's credentials. |
| License freed | Yes. Deactivating a user immediately frees their paid seat, which can be reassigned to a new user without waiting for a billing cycle. |
Watch out for:
- Deactivated users can be reactivated by a Company Admin at any time, which will re-consume a paid seat.
- Board ownership is not automatically transferred on deactivation; admins must manually reassign board ownership if needed.
- If SCIM is configured, deactivating a user in the IdP will automatically deactivate them in Miro; manual deactivation in Miro is also possible independently.
- There is no bulk deactivation UI in the admin console; each user must be deactivated individually through the interface (SCIM deprovision is the only bulk path).
- Deactivated users still appear in the Users list with a 'Deactivated' status and count toward the total user record list, though not toward paid seats.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Full Member seat | Full create/edit access to boards within assigned teams; counts toward paid seat total on Starter, Business, and Enterprise plans. | Starter: $8/user/month (annual) or $10/user/month (monthly); Business: $16/user/month (annual) or $20/user/month (monthly); Enterprise: custom pricing |
| Guest seat | Board-level access only to explicitly shared boards; does not count as a paid Full Member seat. | Included at no additional per-seat charge on Business and Enterprise plans; not available on Free or Starter |
| Free plan member | Unlimited team members on the Free plan with access to up to 3 editable boards. | $0 |
- Where to check usage: Company Settings → Users tab shows total active members, pending invites, and deactivated users. Company Settings → Billing tab shows current seat count and plan details.
- How to identify unused seats: Miro does not provide a native 'last login' or 'last active' date column in the standard admin Users tab for non-Enterprise plans. Enterprise plans have access to audit logs (Company Settings → Audit log) which can be used to identify users with no recent activity. There is no built-in 'inactive user' report on Starter or Business plans.
- Billing notes: Seats are billed per Full Member. Pending invitations consume a seat on Starter and Business plans. Deactivating a user frees the seat immediately. Annual plans are billed upfront; adding seats mid-cycle is prorated. Removing seats on annual plans does not generate a refund until renewal. Enterprise pricing is negotiated and requires a minimum of 30 members.
The cost of manual management
Miro does not provide a native last-login or activity report on Starter or Business plans, so identifying unused seats requires manual cross-referencing or an Enterprise audit log. There is no bulk deactivation UI - every user must be deactivated one at a time through the admin console unless SCIM is in place.
Pending invitations consume a paid seat immediately on Starter and Business plans, before the invitee accepts. Board ownership is not automatically reassigned when a user is deactivated, so orphaned boards require a separate manual cleanup step.
SCIM provisioning - the only practical path for bulk lifecycle management across every app in your stack - is gated behind the Enterprise plan, which requires a minimum of 30 members and custom pricing. SAML SSO must also be fully configured before SCIM can be enabled, adding a hard prerequisite to the setup sequence.
What IT admins are saying
Recurring friction reported by admins centers on three areas. First, the absence of bulk deactivation in the UI is a consistent pain point for teams offboarding multiple users at once.
Second, the lack of last-login visibility on sub-Enterprise plans makes license audits difficult without third-party tooling. Third, the seat-consumption behavior for pending invites catches teams off guard at billing time.
No direct community quotes were available in the provided data.
Common complaints:
- Enterprise plan required for SCIM provisioning, which is the only practical path for bulk user deactivation.
- No bulk deactivation UI in the admin console; admins must deactivate users one at a time manually.
- No native 'last login' or activity report on Starter and Business plans, making it difficult to identify inactive seats.
- Pending invitations consume paid seats immediately upon sending, even before the user accepts.
- Board ownership is not automatically transferred when a user is deactivated, requiring manual reassignment.
- SAML SSO must be fully configured and working before SCIM can be enabled, adding setup complexity.
- Guest access (external collaborators without a paid seat) is not available on the Free or Starter plans.
- No custom roles available; permission granularity is limited to fixed role tiers.
- Must have SAML working first before SCIM setup can begin.
The decision
Choose manual administration if your team is on Starter or Business, your headcount is stable, and offboarding volume is low enough to handle one user at a time. The admin console covers every app team's membership and board access without additional tooling for small-scale changes.
Move to SCIM-backed automation if you are on Enterprise, manage frequent joiners and leavers, or need consistent deprovisioning across every app in your IdP. SAML SSO is a hard prerequisite - plan that configuration first. Without SCIM, bulk deactivation has no supported UI path.
Bottom line
Miro's manual admin workflow is straightforward for day-to-day changes but becomes a bottleneck at scale. The absence of bulk deactivation, no native activity reporting below Enterprise, and immediate seat consumption on pending invites create compounding overhead as team size grows.
For organizations that need reliable, auditable lifecycle management across every app, the Enterprise plan with SCIM and SAML SSO is the only supported path to automation - but it requires upfront SSO configuration and a minimum member threshold before that investment pays off.
Automate Miro 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.
