iManage User Management Guide

• Model type: hybrid
• Description: iManage uses a combination of role-based access control (RBAC) for administrative functions and document-level security (access control lists on workspaces, folders, and documents) for content access. Administrative roles are assigned in Control Center. Document and matter access is governed by security classes and explicit user/group permissions set on each workspace or folder.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Administrative access is role-based with predefined roles. Document access is granular at the workspace, folder, and document level via access control lists, supporting view, edit, and full-control permissions per user or group.

1. Sign in to iManage Cloud Control Center at https://cloudimanage.com.
2. Navigate to Users in the left navigation panel.
3. Click Add User (or the equivalent create button).
4. Enter required user details: first name, last name, email address, and user alias/login name.
5. Assign the user to one or more groups as needed.
6. Assign an administrative role if applicable (e.g., System Administrator, User Administrator).
7. Set the user's security class and default database/library if required.
8. Save the new user record. The user receives an activation or welcome email to set their password (for cloud-managed accounts).

Required fields: First name, Last name, Email address, User alias / login name

Watch out for:

• User alias must be unique across the iManage environment and cannot be changed after creation.
• For organizations using Active Directory or Azure AD integration, users may need to be provisioned in the directory first and then synced or mapped in iManage.
• Security class assignment affects what documents and workspaces the user can access; incorrect assignment can result in over- or under-privileged access.
• iManage Cloud uses named user licensing; adding a user consumes a license seat immediately.

• Can delete users: Unknown
• 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 iManage Cloud Control Center.
2. Navigate to Users.
3. Search for and select the user to be deactivated.
4. Open the user record and set the account status to Inactive or Disabled.
5. Save the change. The user can no longer log in.

Watch out for:

• User alias and historical metadata are permanently retained; the alias cannot be reused for a new user account.
• Workspace or folder ownership assigned to the deactivated user should be manually reassigned to an active user to ensure ongoing access and management.
• Deactivation does not remove the user from group memberships in the system record; administrators should review and clean up group assignments for accuracy.
• If the user was the sole member with Full Control on a workspace, other administrators must manually grant access to that workspace after deactivation.

• Where to check usage: iManage Cloud Control Center > Users (filter by Active status to view current active/licensed users)
• How to identify unused seats: Filter the Users list in Control Center by last login date or account status. Users who have never logged in or have not logged in within a defined period can be identified for review and potential deactivation.
• Billing notes: iManage uses named user licensing. License counts are based on active (non-deactivated) user accounts. Pricing is not publicly listed and must be obtained directly from iManage or an authorized reseller. Deactivating a user frees the seat for reassignment without requiring a new contract amendment in most configurations, but billing cycle impacts should be confirmed with the iManage account team.

Adding a user requires navigating to iManage Cloud Control Center > Users, completing required fields (first name, last name, email, and a unique user alias), assigning groups, and optionally setting an administrative role and security class.

The user alias is permanent and cannot be changed after creation - a known friction point when employee names change or accounts are created with errors. Removing access means deactivating the account (setting status to Inactive);

iManage Cloud does not support permanent deletion, retaining all user records, audit trails, and document history to meet legal industry provenance requirements.

Deactivation does not automatically clean up group memberships or reassign workspace ownership. Administrators must manually audit group assignments and transfer Full Control on any workspaces where the departing user was the sole owner - steps that compound in organizations with large matter portfolios.

Community evidence is not specific enough to quote or summarize yet for this app.

iManage is purpose-built for legal and professional services document management, and its permission model reflects that: granular matter- and workspace-level ACLs give firms precise control over who sees what.

The trade-off is operational overhead - without SCIM or a native automated provisioning path, every joiner, mover, and leaver event in every app that touches iManage requires a manual Control Center action.

Organizations with frequent headcount changes or multiple iManage databases (e.g., separate libraries per office) will feel this most acutely. Teams with stable rosters and an existing Active Directory sync may find the manual overhead manageable, but should still plan for alias immutability and post-deactivation cleanup as recurring administrative tasks.

Bottom line

iManage's manual provisioning path is functional but unforgiving: the permanent user alias, the absence of native SCIM, and the post-deactivation cleanup requirements mean that user lifecycle management demands consistent administrative attention.

Named-user licensing makes every overlooked inactive account a cost exposure, and the lack of built-in last-login reporting means identifying those accounts requires manual effort.

Teams that invest in directory sync configuration will reduce ongoing burden, but every app connected to iManage will still require deliberate, human-driven oversight until a more automated provisioning path is available.