Grammarly User Management Guide

• Model type: role-based
• Description: Grammarly uses a two-role model: Admin and Member. Admins have full team management and configuration access; Members have writing feature access only. There are no granular permission sets or custom roles available.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Coarse - two fixed roles only (Admin, Member). No per-feature permission toggles documented.

1. Sign in to app.grammarly.com and navigate to the Admin panel.
2. Select 'Members' from the left navigation.
3. Click 'Invite members'.
4. Enter one or more email addresses in the invitation field.
5. Select the role to assign (Admin or Member).
6. Click 'Send invitations'.
7. Invitees receive an email invitation and must accept to join the team and consume a seat.

Required fields: Email address of invitee

Watch out for:

• Invitees must accept the email invitation before the seat is consumed and they appear as active members.
• Pending invitations still count toward seat limits on some plan configurations - verify current billing behavior in the admin panel.
• Users must have or create a Grammarly account with the invited email address.
• If SSO is enforced, invited users must authenticate via the configured IdP.

• 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. Sign in to app.grammarly.com and navigate to the Admin panel.
2. Select 'Members' from the left navigation.
3. Locate the member to remove using search or the member list.
4. Click the options menu (three dots or 'Manage') next to the member's name.
5. Select 'Remove from team' or 'Revoke access'.
6. Confirm the removal in the dialog prompt.
7. The member loses team access immediately; the seat is freed for reassignment.

Watch out for:

• Removed users are not notified by default via a system message; they simply lose access to team features.
• If SCIM is configured, deprovisioning via the IdP will automatically remove the user from the Grammarly team without requiring manual admin panel action.
• Admins cannot remove themselves; another admin must perform the removal or ownership must be transferred.
• Removing a user does not delete their personal Grammarly account or personal documents.

• Where to check usage: app.grammarly.com → Admin panel → Members (shows active vs. pending seats) and Analytics/Usage section (shows writing activity per member).
• How to identify unused seats: Admin panel Members list shows last-active date or activity status per member. Admins can sort or filter by activity to identify members who have not used Grammarly within a given period. No automated idle-seat alert is documented.
• Billing notes: Seats are billed per active member. Removing a member frees the seat for the next billing cycle or immediately depending on plan terms. Annual plans may not prorate mid-cycle seat reductions - verify with Grammarly billing support. The legacy 'Business' plan has been merged into 'Pro'; existing Business customers were migrated.

Without SCIM, admins invite users one at a time via the Members panel; there is no CSV bulk import and no domain-based auto-join. Pending invitations may count against seat limits before users accept, making available seat counts unreliable until acceptances clear.

Identifying unused seats requires manually sorting the Members list by last-active date - no automated idle-seat alert exists. Removing a user revokes team access immediately and frees the seat, but the user's personal Grammarly account persists.

Admins cannot remove themselves; ownership must be transferred or another admin must perform the action.

Practitioners consistently flag the SSO-before-SCIM sequencing as the most high-impact setup constraint - teams that attempt to enable SCIM without a fully active SAML configuration hit a hard block and must backtrack.

The absence of CSV import and domain whitelisting forces manual invitation management at scale, which compounds as headcount grows.

Seat-count confusion around pending invitations is a recurring pain point: seats may appear consumed before any user has logged in. Annual plan customers should verify mid-cycle seat reduction behavior directly with Grammarly billing, as prorating is not guaranteed.

Common complaints:

• SAML SSO must be fully configured before SCIM provisioning can be enabled, creating a multi-step prerequisite that delays automated provisioning.
• Group provisioning via SCIM is only available on Enterprise and requires a separate request to Grammarly support - not self-serve.
• No CSV bulk import for users is documented; bulk adds require SCIM/IdP integration or manual individual invitations.
• No domain-based auto-join (domain whitelisting) is available; all users must be individually invited.
• Admins report difficulty identifying unused seats because there is no built-in idle-seat alert or automated report.
• Pending invitations may consume seat allocations before users accept, causing confusion about available seat counts.
• Only two roles (Admin and Member) are available - no granular permissions for power users or team leads.
• Removing a user does not notify them, which can cause confusion when users lose access unexpectedly.
• Token management and API credential handling for some IdP SCIM integrations (e.g., Okta) requires manual steps in both the IdP and Grammarly admin panel.

Manual administration is workable for small teams where turnover is low and SSO is not yet in place. At that scale, the two-role model is sufficient and the Members panel is straightforward.

Once every app in your provisioning workflow needs to reflect accurate Grammarly seat state, the absence of bulk import, domain auto-join, and idle-seat alerts creates compounding overhead.

SCIM via an IdP (Okta, Entra ID, or OneLogin) is the documented path to automation, but it requires Pro or Enterprise tier and a working SAML SSO configuration as a prerequisite. Enterprise is the only tier with group provisioning, and even then it requires a support request - factor that lead time into rollout planning.

Bottom line

Grammarly's admin tooling covers the basics reliably but offers little flexibility: two roles, no bulk import, no domain auto-join, and no idle-seat alerts.

Every app decision around Grammarly seat management will eventually surface the SSO-before-SCIM sequencing requirement, so teams should treat SAML configuration as the first milestone, not an afterthought.

Manual administration is viable at small scale; anything larger warrants investing in the SCIM setup upfront to avoid per-user invitation overhead and seat-count ambiguity.