Summary and recommendation
SysAid 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.
SysAid organizes users into two distinct populations: admin/agent accounts, which consume paid license seats and operate the service desk, and end users, who access only the Self-Service Portal and do not consume agent seats.
Permissions for admins are inherited from admin groups, not set per individual - changing a group's permission profile affects every member of that group.
SCIM-based provisioning is available but gated behind the Enterprise plan and requires SSO to be fully configured first.
Quick facts
| Admin console path | Settings (gear icon) > Administrator > 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 |
|---|---|---|---|---|---|
| Administrator (Admin) | Full access to SysAid configuration, service desk operations, user management, reporting, and all modules enabled on the account. Can create and manage other admins and end users. | Cannot exceed the number of licensed admin seats purchased. | Reported at $79/user/month (Help Desk) or $108/user/month (ITSM); exact per-seat cost depends on contracted plan. | Admin seats are the primary licensed seat type; adding admins consumes a paid license seat. | |
| End User (Service User) | Can submit and track service requests via the Self-Service Portal. No access to the admin/agent interface. | Cannot manage tickets on behalf of others, access admin settings, or run reports. | End users are typically not counted as paid agent seats; licensing is based on admin/agent count and managed assets. | End-user accounts can be created manually, imported via LDAP/AD, or auto-created on first login via SSO. Large end-user populations do not directly consume agent license seats. | |
| Admin Group Member | Subset of admin permissions defined by the admin group's permission profile. Can be scoped to specific modules, categories, or service desk functions. | Cannot perform actions outside the permission profile assigned to their admin group. | Consumes an admin/agent license seat. | Permissions are inherited from the admin group, not set individually per user. Changing a group's profile affects all members. |
Permission model
- Model type: role-based
- Description: SysAid uses admin groups with associated permission profiles to control what administrators can access and do. Each admin is assigned to one or more admin groups; the group's permission profile determines module access, ticket visibility, and configuration rights. End users have a fixed, non-configurable permission set limited to the Self-Service Portal.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Module-level and category-level scoping within admin groups. Permissions can be set per module (e.g., Incidents, Problems, Changes, Assets) and per service category routing.
How to add users
- Log in as an administrator and navigate to Settings > Administrator > Administrators (for admin users) or Settings > End Users > End Users (for end users).
- Click 'New' or the add button to open the user creation form.
- Enter required fields (username, display name, email address, password or authentication method).
- Assign the user to an admin group (for admin users) to apply the appropriate permission profile.
- Save the record. The user can now log in with the configured credentials or SSO.
Required fields: Username, First name, Last name, Email address, Password (if not using SSO/LDAP authentication)
Watch out for:
- Admin users must be assigned to at least one admin group; without a group assignment, permissions may be undefined.
- If LDAP sync is active, manually created users may be overwritten or duplicated if the same username exists in the directory.
- SSO-only environments may require the user to exist in the IdP before they can authenticate; SysAid does not auto-provision admin accounts from IdP without SCIM or LDAP sync.
- SCIM provisioning (for automated IdP-driven user creation) requires the Enterprise plan and an SSO prerequisite.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Settings > End Users > Import Users (CSV import available for end users); admin bulk import via LDAP sync. |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (SCIM via Okta or Azure AD requires Enterprise tier and SSO add-on) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: SysAid documentation indicates that both admin and end-user accounts can be deleted from the user management interface. Admins can also be deactivated (disabled) without deletion, which prevents login while preserving the account record and associated history. The specific UI path is the user record's status field or a delete action in the user list.
- Navigate to Settings > Administrator > Administrators (for admin users) or Settings > End Users > End Users (for end users).
- Open the user record.
- Set the account status to inactive/disabled, or use the delete option to remove the account entirely.
- Save changes.
| Data impact | Behavior |
|---|---|
| Owned records | Service records (tickets, incidents, changes) previously assigned to or submitted by the user remain in the system and retain their historical assignment data. |
| Shared content | Shared views, filters, or reports created by the user may remain accessible to other admins depending on sharing settings. |
| Integrations | If the user was mapped in an LDAP or SSO integration, deactivating in SysAid does not automatically disable the IdP account; IdP-side deprovisioning must be handled separately unless SCIM is configured. |
| License freed | Deactivating or deleting an admin user frees the consumed admin/agent license seat, making it available for reassignment. |
Watch out for:
- Deactivating a user in SysAid does not revoke their IdP session or disable their IdP account; SSO users may still be able to authenticate if the IdP account remains active.
- If LDAP sync is scheduled, a deactivated user whose AD account is still active may be re-enabled on the next sync cycle depending on sync configuration.
- Deleting a user is generally irreversible; associated ticket history is retained but the user profile record is removed.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Admin / Agent seat | Full access to the SysAid admin interface, service desk, and configured modules. Required for IT staff managing tickets and system configuration. | Reported at $79/user/month (Help Desk plan) or $108/user/month (ITSM plan); Enterprise pricing is custom. |
| End User (Self-Service Portal) | Access to the Self-Service Portal for submitting and tracking requests only. Not counted as a paid agent seat. | Included; end users do not consume agent license seats. |
- Where to check usage: Settings > General Settings > License Information (displays current licensed seat count and active admin/agent usage).
- How to identify unused seats: Review the Administrators list (Settings > Administrator > Administrators) and filter by last login date or inactive status to identify admin accounts that have not been used recently.
- Billing notes: SysAid pricing is based on the number of admin/agent seats and the number of managed assets. End users are not separately licensed. Pricing is not publicly listed for all tiers; Enterprise pricing requires contacting sales. The SSO Connector and SCIM provisioning are add-on or Enterprise-tier features.
The cost of manual management
Every app with manually managed user accounts carries a compounding operational cost: stale admin accounts that were never deactivated, LDAP sync conflicts from accounts created outside the directory, and re-enabled users when AD sync runs against a deactivated SysAid record.
In SysAid, admin seats are the primary licensed unit - each active admin account consumes a paid seat regardless of how frequently that person logs in. Identifying unused seats requires manually filtering the Administrators list by last login date, a process that does not scale for larger IT teams.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Use manual user management in SysAid if your team is small, your IdP is not Okta or Azure AD, or you are not on the Enterprise plan.
For any environment where admin turnover is frequent or end-user populations are large, LDAP sync or SCIM provisioning will reduce the overhead of keeping every app's user state accurate.
Be aware that neither LDAP sync nor SCIM eliminates the need for a parallel IdP deprovisioning step - SysAid account deactivation and IdP session revocation are independent actions.
Bottom line
SysAid's manual user management is functional for small, stable teams but introduces real operational risk at scale: LDAP sync conflicts, orphaned admin seats, and the absence of automatic IdP propagation on deactivation mean that every app connected through SysAid's identity chain requires its own deprovisioning verification.
Teams that need reliable lifecycle automation should treat SCIM via Okta or Azure AD as a prerequisite, not an enhancement - and should budget for the Enterprise plan and SSO configuration work that unlocks it.
Automate SysAid 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.
