Absorb LMS User Management Guide

• Model type: hybrid
• Description: Absorb uses a role-based model with four locked default admin roles (System Admin, Admin, Instructor, Reporter) that cannot be edited. System Admins and Admins with Role (View + Modify) permissions can create custom admin roles with granular view/modify permissions per LMS section. A separate Manager Roles system governs the Manager Experience independently. Admin visibility scope (which users an admin can see and manage) is controlled by a User Management setting on each admin's profile (All, Department, or Group), which operates in tandem with role permissions.
• Custom roles: Yes
• Custom roles plan: All plans (System Admin or Admin with Role modify permission required to create)
• Granularity: Per-section View and Modify permissions across Users, Courses, Reports, Enrollments, Departments, Groups, Roles, and add-on modules. Modify always requires View to be enabled. Some permissions have hidden dependencies (e.g., Course Activity report requires View Online Courses). A small number of hidden permissions exist in default roles that cannot be added to custom roles.

1. Log in to the Admin Experience.
2. Open the Users menu from the left-hand navigation.
3. Select Users to open the Users Report.
4. Click the Add User button in the Actions menu on the right-hand side.
5. Fill in required fields: First Name, Last Name, Username, Department, and Password.
6. Set Account type (Learner is default; enable Admin or Instructor toggle if needed).
7. Assign a Role if enabling Admin access (under Account > Admin section).
8. Set User Management scope for admin users (All, Department, or Group).
9. Click Save.

Required fields: First Name, Last Name, Username (must be unique across all users, even if Employee ID or External ID is used as the unique identifier), Department (each user must belong to exactly one department), Password (required even if SSO is enabled)

Watch out for:

• Username cannot be changed after account creation.
• A password must be set even for SSO users.
• Users are set to Learner by default; Admin or Instructor access must be explicitly toggled on.
• Each user can belong to only one Department.
• CSV import cannot update the Username field for existing users.
• Email Address and Gender fields are not required but trigger a format validation check if columns are present in a CSV import - blank values will fail validation, potentially requiring the CSV to be split into multiple files.
• Scheduled data imports (HRIS/FTP-based) are an additional paid service requiring Professional Services engagement.

• Can delete users: Yes
• Delete/deactivate behavior: Absorb supports both deactivation (setting status to Inactive) and permanent deletion. Deactivation preserves all user data and enrollment history; the user cannot log in but remains searchable by filtering for Inactive status. Deletion is permanent and removes the user record. Deactivation is the recommended approach for offboarding to preserve historical training records.

1. Log in to the Admin Experience.
2. Open the Users menu from the left-hand navigation and select Users.
3. The Users Report defaults to Active users only.
4. Select the user from the report (checkbox).
5. From the Actions menu on the right-hand side, select the option to deactivate (set Status to Inactive).
6. Confirm the action.

Watch out for:

• Deactivating a user stops all their scheduled reports from sending, even though the user record is preserved.
• There is no granular permission to allow an admin to only deactivate/activate users without also being able to edit or delete them - the 'Modify' permission grants all three capabilities simultaneously.
• Delete and Modify user permissions cannot be separated; admins with Modify access can also delete users.
• Inactive users do not appear in the default Users Report view; admins must filter by Status = Inactive to find them.
• Username cannot be reused after deletion - it remains reserved in the system.

• Where to check usage: Admin Experience > Reports section (User Activity Report, Course Activity Report). Active user counts are not surfaced in a dedicated license dashboard; usage must be derived from reports or confirmed with the Absorb account/CSM team.
• How to identify unused seats: Run the User Activity Report filtered by last login date or enrollment activity. Filter the Users Report by Status = Active to identify users who have never logged in or have not been active within the billing window. Inactive users do not appear in the default view and must be filtered separately.
• Billing notes: Pricing is fully custom and quote-based with no public pricing tiers. Billing is typically tied to active learners, not total registered users. SSO is a paid add-on on all plan tiers. SCIM provisioning requires Enterprise tier plus SSO add-on. Scheduled data imports (HRIS/FTP) are billed separately through Professional Services. Add-on modules (Absorb Create, Absorb Analyze, Absorb Skills, Absorb Content, eCommerce, Mentorship) are separately priced SKUs. Seasonal usage spikes or external audience training can trigger overage fees or tier changes - confirm thresholds and measurement windows in the contract.

Manual user management in Absorb compounds across every app touchpoint in your environment. Profile changes from an HRIS - department transfers, job title updates, name corrections - must be applied individually in Absorb because SAML JIT provisioning creates accounts on first login only and never syncs subsequent attribute changes.

The deactivate and delete permissions cannot be separated from the general Modify Users permission, so granting any admin the ability to offboard users also grants them edit and delete access. Admins must filter by Status = Inactive to find deactivated users, since they are hidden from the default Users Report view.

Scheduled reports tied to a deactivated user stop sending silently, with no system alert.

Recurring friction points reported by Absorb administrators center on permission granularity and provisioning gaps. The inability to grant deactivation-only access without also granting full edit and delete rights is a documented open feature request.

Reviewers on G2 and Capterra note that role customization flexibility is limited relative to the platform's overall configurability.

SSO being a paid add-on on every plan tier - rather than included at any base tier - is a consistent cost surprise, particularly for teams that assumed SSO was standard.

The automatic expansion of System Admin and default Admin role permissions when new LMS features are released has also been flagged as an unexpected access-control risk.

Common complaints:

• SSO is a paid add-on on every plan tier, not included in base pricing.
• SAML provisioning is one-time only - creates accounts on first login but never updates existing user attributes, forcing manual account management for profile changes.
• Full SCIM provisioning requires both Enterprise tier and SSO add-on, and only works on 'Absorb 5 - New Learner Experience'; older implementations require migration.
• Hidden costs for feature upgrades (SCIM, SSO, scheduled data imports, Professional Services).
• Deactivate and delete permissions cannot be separated from the general Modify Users permission, preventing admins from granting narrow offboarding-only access.
• Default Admin and System Admin roles automatically receive new permissions when new features are released, creating unexpected access expansion.
• Out-of-box reporting is limited; advanced analytics require the separately priced Absorb Analyze add-on.
• CSV import cannot update usernames for existing users.
• CSV imports for new users can only target one Department per file; multi-department imports require splitting files.
• Common workflows involve many clicks and lack streamlining, which is frustrating for repetitive admin tasks.
• Admin role customization flexibility is limited in certain edge cases, sometimes forcing admins to either grant too much or too little access.

Representative quotes (verbatim):

We need to be able to allow certain admins to only activate or deactivate users, but not be able to edit or delete users... this is currently not possible.

• Absorb Ideas community post (unattributed user) (https://ideas.absorblms.com/ideas/LMS-I-667)

The flexibility when it comes to the customization of admin and manager roles is quite limited.

• G2 reviewer (verified user, role/company not disclosed) (https://www.g2.com/products/absorb-software-absorb-lms/pricing)

The main shortcoming we experienced is that some common workflows could be streamlined. They can involve a lot of clicks.

• Capterra verified reviewer (https://www.capterra.com/p/61763/Absorb-LMS/)

Absorb LMS manual user management is workable for organizations with stable, low-churn user populations and a dedicated LMS administrator. It becomes operationally expensive when headcount changes frequently, when users span multiple external audiences (clients, partners) with different billing types, or when compliance requires tight, auditable offboarding workflows.

The permission model's inability to separate deactivation from full user modification is a concrete blocker for teams that need to delegate narrow offboarding tasks.

SCIM provisioning resolves the attribute-sync gap but requires Enterprise tier plus a separately purchased SSO add-on, and only functions on the Absorb 5 New Learner Experience - older portal implementations require migration before SCIM can be enabled.

Bottom line

Absorb LMS gives administrators a functional but manually intensive user lifecycle workflow. Every app or system feeding identity data into Absorb requires a separate update process unless SCIM is in scope, and SCIM itself sits behind two paid prerequisites (Enterprise tier and SSO add-on).

The permission model is hybrid and reasonably granular for most admin delegation needs, but the inability to isolate deactivation rights from broader user modification access is a real constraint for security-conscious teams.

Organizations with high user turnover, external learner audiences, or strict offboarding audit requirements should factor the cost of those add-ons - and the migration effort for older portal versions - into their total ownership calculation before committing to a manual-only approach.