Agiloft User Management Guide

• Model type: hybrid
• Description: Permissions are controlled through a three-layer model. Groups control access to tables, records, and fields; they are configured via Setup > Access > Manage Groups using the Group Permissions Wizard. Teams control UI elements such as color scheme, views, and default home page. Roles combine a Group and Team to determine a user's overall permissions level and license flag. Users assigned to multiple groups receive the superset of those groups' access settings. Permissions are configurable at the table level, record level (own records vs. others' records), and field level. Menu-level permissions (views, saved searches, reports, print templates, email templates) are also configurable per group per table.
• Custom roles: Yes
• Custom roles plan: All plans
• Granularity: Table-level, record-level (own vs. others), and field-level permissions per group; menu-level permissions (views, saved searches, reports, print templates, email templates) also configurable per group per table.

1. Log in as an administrator or a user with permission to manage other users.
2. Navigate to the People table and select the appropriate subtable: Employees (for internal staff) or External Users (for non-employees).
3. Click New to create a new user record.
4. Complete required fields: First Name, Last Name, Login (username), and Password.
5. Assign the user to the necessary Groups and set a Primary Team to control their access and interface.
6. Optionally assign a Role, which links the appropriate Group and Team and sets the license flag.
7. Click Save (Finish) to create the record.
8. If using SAML/SSO (e.g., Okta or Microsoft Entra ID), an Employee record is auto-generated on the user's first login via JIT provisioning; no manual creation is required for SSO users.

Required fields: First Name, Last Name, Login (username), Password

Watch out for:

• Users must be assigned to at least one Group and a Primary Team to be able to log in; without group assignment, login is blocked.
• JIT provisioning via SAML creates the user record on first login but does not handle deprovisioning; offboarding must be performed manually in Agiloft.
• Even if a user authenticates through LDAP or Active Directory, Agiloft creates a local user record used in rules and other system functions.
• External users created without a login value will have their login auto-set to their email address by a system rule, but will not be able to log in unless placed in a group.
• Three system accounts (anonymous, register, guest) must never be deleted as they are required for system functionality.
• Four admin-level accounts (admin, busadmin, ewsystem, system) must be given highly secure passwords and handled with caution; deactivating them can break system or support functionality.

• Can delete users: No
• Delete/deactivate behavior: Agiloft strongly recommends deactivating rather than deleting user accounts. Deactivation retains the account's activities in audit logs and all associated records while removing the user's ability to log in. Deleting a user record is technically possible for regular records but is explicitly discouraged for any person who has interacted with the system, as deletion breaks audit trails and history. Certain system accounts (anonymous, register, guest, admin, busadmin, ewsystem, system) must never be deleted.

1. Log in as an administrator or a user with permission to manage other users.
2. Navigate to the People table and search for the user to deactivate.
3. Open the user's record for editing.
4. Remove all Group memberships from the user record.
5. Clear the Primary Team field.
6. Save the record.
7. Optionally: navigate to Setup gear > License > Manage Licenses > Manage Assigned Licenses > View/Manage Assigned License, select the user, and click 'Terminate a user' to immediately free the license rather than waiting for the 24-hour inactivity expiry.

Watch out for:

• Never deactivate the 'admin' login account; it is used by the system for background activities.
• The 'EW System' and 'System' accounts are used by Agiloft Support; deactivating them will break support access.
• Deactivated users can only be re-activated by an administrator or a user with permission to manage other users.
• Deactivation prevents login and disables the password reset option for that account.
• JIT-provisioned SSO users are not automatically deprovisioned when removed from the IdP; the Agiloft record must be manually deactivated.
• Setting empty values in both the Groups and Primary Team fields prevents login but preserves all history; this is the recommended deactivation method per official documentation.

• Where to check usage: Setup gear > License > View Usage (shows all users currently consuming a license, date of last login, and license usage details). In KB Management: KB Management > License > View Usage (shows licenses associated with individual users).
• How to identify unused seats: Navigate to Setup > License > View Usage to review last login dates per user. For floating licenses, the inactivity timeout automatically reclaims licenses from inactive sessions. Admins can use the 'Terminate a user' action on the Manage Assigned Licenses screen to manually free a license. Periodic audits are recommended: export the People table to Excel and filter by last login date to identify inactive accounts.
• Billing notes: Subscription-based per user with volume-based pricing. License types include Assigned Power User, Floating Power User, Self-Serve, and Read/Request. If no suitable license is available when a user attempts to log in, the system blocks login and can send an automated 'Out of Licenses' email notification, configurable at Setup > License > Out of Licenses Email. When multiple licenses of the same type exist on a KB, the system uses the most recently installed one. Enterprise Production license requests must be accompanied by a purchase order. Implementation costs range from approximately $5,000 to $50,000+ depending on deployment size.

Without automation, every joiner requires an administrator to navigate to the People table, create a record, assign Groups and a Primary Team, and set the correct license type - or rely on JIT to handle creation on first SSO login, which still requires a pre-configured SAML attribute mapping.

Every leaver requires a manual deactivation: removing all Group memberships, clearing the Primary Team, and optionally triggering a license termination via Setup > License > Manage Licenses to avoid waiting for the 24-hour inactivity expiry.

Mover events - role changes, department transfers - require manual updates to Group assignments and potentially license type changes, with no automated sync from HR systems. The built-in 'admin' account must never be deactivated, and three system accounts (anonymous, register, guest) must never be deleted, adding operational risk to any bulk deprovisioning workflow.

Floating licenses reclaim automatically after inactivity timeout, but Assigned Power User licenses require manual termination to free seats promptly.

Administrators consistently flag the Groups/Teams/Roles permission model as the steepest part of the learning curve. The relationship between tables when configuring permissions is frequently described as non-intuitive, and changes to group permissions or field configurations can produce unintended side effects across related tables and subtables.

Verified reviewers on G2 and Capterra note that the platform's power comes with a maintenance cost, and that small or non-technical teams often require professional services support to reach operational self-sufficiency.

The absence of native SCIM is a recurring friction point: JIT provisioning handles creation but leaves deprovisioning entirely to manual processes, which creates audit and access risk in fast-moving organizations.

Common complaints:

• No native SCIM means limited lifecycle automation; deprovisioning must be done manually even when using SAML JIT provisioning.
• JIT provisioning does not handle deprovisioning; users removed from the IdP retain active Agiloft accounts until manually deactivated.
• Understanding the relationships between tables when setting up new fields and revising user permissions is frequently cited as confusing.
• Steep learning curve for administrators, particularly for non-technical users configuring the Groups/Teams/Roles permission model.
• The permission configuration backend is powerful but takes significant time to learn; small or non-technical teams often require professional services support.
• Customization changes to permissions or fields can unintentionally affect other fields or data, making cleanup and modifications challenging.
• The admin UI is considered non-intuitive and dated by some users, particularly for user and permission management tasks.
• Issues with Agiloft's approach to managing implementation and licensing have been cited as friction points by some customers.

Representative quotes (verbatim):

Understanding the relationships between tables when setting up new fields and revising user permissions can be confusing.

• Verified user review, Capterra (https://www.capterra.com/p/101273/Agiloft/reviews/)

While the platform is powerful this comes at a cost in terms of how easy the platform is to maintain.

• Verified user review, G2 (https://www.g2.com/products/agiloft-agiloft-contract-management-suite/reviews)

For a small, specialised, non-technical Team this has meant a steep learning curve in reaching some level of self-sufficiency.

• Verified user review, G2 (https://www.g2.com/products/agiloft-agiloft-contract-management-suite/reviews)

Manual administration of Agiloft is viable for organizations with stable headcount, a dedicated technical administrator, and a low volume of user changes. It becomes operationally expensive when onboarding or offboarding volume is high, when the team lacks Agiloft-specific expertise, or when audit requirements demand timely deprovisioning.

The JIT provisioning model works well for onboarding but creates a structural gap for offboarding: every app that relies on IdP removal as the deprovisioning signal will fail here, because Agiloft does not receive that signal.

Organizations with strict access governance requirements should plan for a compensating control - either REST API automation or a scheduled audit process - to close the deprovisioning gap.

License type selection also requires deliberate planning: Self-Serve users cannot participate in approval workflows or use Word/Outlook integrations, and misassigning license types is a common source of support escalations.

Bottom line

Agiloft's manual user management is functional but labor-intensive, with the JIT provisioning model covering onboarding and leaving offboarding entirely to administrators. The three-layer Groups/Teams/Roles permission model is powerful and granular but carries a steep learning curve, and misconfigured permissions can have cascading effects across tables.

Organizations should budget for dedicated administrator time and establish a repeatable deprovisioning checklist - removing Group memberships, clearing the Primary Team, and manually terminating licenses - to maintain access hygiene.

For teams with high user churn or strict compliance requirements, the absence of native SCIM makes REST API automation or a third-party identity orchestration layer a practical necessity rather than an optional enhancement.