Moz User Management Guide

• Model type: role-based
• Description: Moz Pro uses a simple two-tier role model: Account Owner and invited Users. There are no granular permission sets or custom roles. The Account Owner controls billing and user management; invited users access campaigns and tools but cannot modify account settings.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Coarse - two fixed roles only (Owner and User). No per-campaign or per-feature permission controls documented.

1. Log in to Moz Pro as the Account Owner.
2. Click the account avatar or name in the top-right corner to open the account menu.
3. Navigate to Account Settings > Users (or go directly to https://moz.com/account/users).
4. Click 'Invite User' or 'Add User'.
5. Enter the invitee's email address.
6. Send the invitation. The invitee receives an email to accept and set up access.

Required fields: Invitee email address

Watch out for:

• Only the Account Owner can invite users; invited Users cannot add others.
• The number of seats available depends on the plan tier; exceeding the limit requires a plan upgrade.
• Invitees must accept the email invitation before they can access the account.
• Invited users access the same Moz Pro subscription and its campaigns - there is no separate workspace isolation per user.

• Can delete users: Yes
• Delete/deactivate behavior: The Account Owner can remove (revoke access for) an invited user from the Users management page. Removal revokes the user's login access to the account. Moz Pro does not appear to offer a distinct 'deactivate' state separate from full removal based on available documentation.

1. Log in to Moz Pro as the Account Owner.
2. Navigate to Account Settings > Users (https://moz.com/account/users).
3. Locate the user to be removed.
4. Click the remove or revoke option next to the user's name.
5. Confirm the removal.

Watch out for:

• Removing a user is immediate; the user loses access upon removal.
• There is no documented grace period or re-invitation shortcut - a removed user must be re-invited via the standard invite flow.
• Account Owner cannot be removed without transferring ownership first, which requires contacting Moz support.

• Where to check usage: Account Settings > Users (https://moz.com/account/users) - shows current invited users against the plan's seat limit.
• How to identify unused seats: Review the Users list for accounts that have not accepted their invitation (pending status) or that the team no longer needs; remove unused invites to free seats.
• Billing notes: Moz Pro plans are subscription-based (monthly or annual). The number of included user seats varies by plan tier. Exact seat counts per plan should be verified at moz.com/pricing as they are subject to change. Annual billing provides a 10–25% discount versus monthly billing. No per-seat add-on pricing is publicly documented; seat expansion is achieved by upgrading the plan tier.

Every app that lacks automated provisioning creates the same operational drag: admins must manually invite each new hire, track pending invitations, and remove leavers one by one through the UI.

In Moz Pro, seat counts are tied to plan tier rather than sold individually, so hitting a limit means a full plan upgrade - not a simple seat add-on. Ownership transfers require contacting Moz support directly, adding friction whenever team structure changes.

Community feedback surfaces three recurring friction points. First, the number of seats included per plan tier is not clearly displayed during the invite flow, leading to unexpected upgrade prompts.

Second, the flat permission model frustrates teams that want to give contractors or agency clients access to only specific campaigns.

Third, the Account Owner transfer process - which requires a support ticket rather than a self-serve UI action - is consistently flagged as a blocker during offboarding or team transitions.

Common complaints:

• Users report confusion about how many additional seats are included per plan tier, as this information is not prominently displayed during the invite flow.
• Some users note that the Account Owner role cannot be self-transferred and requires contacting Moz support, which adds friction when team ownership changes.
• Community threads indicate frustration that Moz Pro lacks granular permission controls - all invited users get the same level of access with no way to restrict specific campaigns or features.
• Users on lower-tier plans report hitting seat limits unexpectedly and needing to upgrade their plan to add additional team members.

Moz Pro is a reasonable fit for small SEO teams comfortable with manual user administration. Teams that need role-based access controls, per-campaign permissions, or automated provisioning will find the current model limiting. If your organization already uses OneLogin, the Moz connector provides the only semi-automated provisioning path documented.

Otherwise, every app lifecycle event - onboarding, offboarding, ownership change - requires direct UI action by the Account Owner.

Bottom line

Moz Pro's user management is functional but minimal: two fixed roles, seat limits tied to plan tier, and no self-serve ownership transfer. For small teams with stable membership, the manual invite-and-remove workflow is manageable.

For organizations with frequent team changes or a need for granular access controls, the flat permission model and absence of any provisioning API will require compensating processes to stay on top of access hygiene.