Summary and recommendation
WalkMe 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.
WalkMe's admin console lives at editor.walkme.com under Account Settings → User Management.
Admins invite users by email, assign one of four predefined roles (Admin, Editor, Viewer, Publisher), and scope each user to one or more WalkMe Systems.
There are no custom roles;
permission granularity is limited to role plus system assignment.
Quick facts
| Admin console path | WalkMe Editor → Account Settings → User Management |
| 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 access to all systems, settings, user management, billing, and content across all environments. | Only Admins can manage other users and configure SSO/SCIM settings. | |||
| Editor | Can create, edit, and publish WalkMe content (Walk-Thrus, SmartTips, etc.) within assigned systems. | Cannot manage users, access billing, or modify account-level settings. | Access is scoped to specific systems assigned by an Admin; cross-system access requires explicit assignment. | ||
| Viewer | Read-only access to WalkMe content and analytics within assigned systems. | Cannot create, edit, or publish content; cannot manage users or settings. | |||
| Publisher | Can publish content created by Editors but may have restricted editing capabilities depending on configuration. | Cannot manage users or account settings. | Availability of this role may depend on account configuration; verify with WalkMe account team. |
Permission model
- Model type: role-based
- Description: WalkMe uses a role-based access control model. Predefined roles (Admin, Editor, Viewer) are assigned per user. Permissions are further scoped by which WalkMe Systems (applications) a user is granted access to, allowing system-level isolation between teams.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role assignment is per-user and per-system. Admins can restrict Editors and Viewers to specific systems within the account.
How to add users
- Log in to the WalkMe Editor at editor.walkme.com.
- Click the account avatar or menu in the top-right corner and navigate to Account Settings.
- Select the 'Users' or 'User Management' tab.
- Click 'Invite User' or 'Add User'.
- Enter the new user's email address.
- Select the appropriate role (Admin, Editor, Viewer).
- Assign the user to one or more WalkMe Systems as applicable.
- Click 'Send Invitation' or 'Save'. The user receives an email invitation to set up their account.
Required fields: Email address, Role, System assignment (at least one)
Watch out for:
- Invited users must accept the email invitation before they can log in; pending invitations occupy a seat.
- If SSO is enforced on the account, users must authenticate via the configured IdP and cannot use a local password.
- System assignment is required; a user with no system assigned cannot access any content.
| 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: Yes
- Delete/deactivate behavior: WalkMe Admin Console allows Admins to remove (delete) users from the account. When a user is removed, they lose access immediately. Official documentation does not describe a separate 'deactivate' state distinct from deletion for manually managed users; SCIM deprovisioning sets the user to inactive.
- Log in to the WalkMe Editor at editor.walkme.com.
- Navigate to Account Settings → Users.
- Locate the user to be removed.
- Click the options menu (three dots or similar) next to the user.
- Select 'Remove User' or 'Delete'.
- Confirm the action when prompted.
| Data impact | Behavior |
|---|---|
| Owned records | Content (Walk-Thrus, SmartTips, etc.) created by the removed user remains in the account and is not deleted. |
| Shared content | Shared content and published items remain accessible to other users and end-users. |
| Integrations | Not documented |
| License freed | Removing a user frees the seat, making it available for reassignment. |
Watch out for:
- If SCIM provisioning is active, user removal should be managed from the IdP to ensure the SCIM deprovisioning flow executes correctly; manual deletion may cause sync inconsistencies.
- Removing the only Admin on an account may lock out administrative access; ensure at least one Admin remains.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| WalkMe for Employees | Named seats for internal users (employees) accessing WalkMe-enabled internal applications. | Custom pricing; estimated $1–2.50/user/month based on third-party reports. |
| WalkMe for Customers | Usage-based or MAU-based licensing for external end-users of customer-facing applications. | Custom pricing; based on monthly active users (MAU) or application volume. |
- Where to check usage: WalkMe Editor → Account Settings → Users (shows current invited/active users and seat consumption)
- How to identify unused seats: Review the Users list in Account Settings for users who have not accepted their invitation (pending status) or who have not logged in recently. WalkMe Insights analytics can show per-user engagement data to identify inactive accounts.
- Billing notes: WalkMe uses custom-quote, contract-based pricing. Seat counts and MAU limits are defined in the contract. Overages and true-ups are handled at renewal. Multi-year commitments may include discounts. Contact the WalkMe account team to adjust seat counts mid-contract.
The cost of manual management
Every app in your stack that relies on WalkMe for employee guidance creates a manual provisioning touchpoint. Invited users occupy a seat the moment the invitation is sent - before they ever log in - so stale pending invitations silently inflate your seat count. Without automation, offboarding requires a manual deletion step in the console;
there is no deactivate-without-delete state for manually managed users, which complicates audit trails. Role changes and system reassignments must also be applied one user at a time.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management is viable for small, stable teams where user turnover is low and system assignments rarely change.
It becomes a liability at scale: every app a user touches within WalkMe requires explicit system assignment, role changes have no bulk-edit path, and offboarding gaps leave active seats on a contract that bills by named user or MAU.
Teams with Okta or Microsoft Entra ID already in place and an Enterprise WalkMe contract should evaluate SCIM provisioning to close those gaps. Teams without an enterprise IdP or on a sub-Enterprise plan have no automated path and should account for manual overhead in their operational planning.
Bottom line
WalkMe's manual user management is straightforward for small teams but does not scale cleanly. Seat consumption begins at invitation, not activation, and the absence of custom roles or bulk operations means administrative overhead grows linearly with headcount.
Every app scoped to a user requires deliberate assignment, and offboarding without SCIM leaves a manual deletion step as the only access revocation mechanism. Teams on the Enterprise plan with an Okta or Entra ID deployment should prioritize SCIM to reduce that overhead;
everyone else should build explicit provisioning and deprovisioning steps into their IT workflows.
Automate WalkMe 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.
