Summary and recommendation
BMC Remedy (Helix ITSM) 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.
BMC Remedy (Helix ITSM) manages users across two separate but linked records: an AR System User record (controls login and license) and an ITSM People record (controls functional identity and module access).
Both must exist and be correctly configured for an agent to work as expected.
There is no native SCIM endpoint, so every app that needs to reflect Remedy identity state requires a manual or API-driven sync.
Quick facts
| Admin console path | AR System Administration Console → User Management (accessed via the AR System Mid Tier or Helix Portal admin interface) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Fixed License User | Full concurrent access to all licensed AR System and ITSM applications at any time; not subject to concurrent-use limits. | Cannot exceed the number of fixed seats purchased. | ~$115/user/month (custom enterprise pricing; varies by contract) | Fixed seats are named and tied to a specific login ID; reassigning a fixed seat to a different user requires administrative action. | |
| Floating (Concurrent) License User | Access to ITSM applications up to the purchased concurrent-session limit; sessions are released when the user logs out. | Cannot log in if all concurrent slots are occupied. | Sessions that are not properly closed (e.g., browser crash) may hold a floating slot until the session timeout expires. | ||
| Read License User | Read-only access to AR System forms and ITSM records; cannot create or modify records. | Cannot submit, modify, or close tickets. | Read license users still consume a named seat and must be explicitly assigned the Read license type in the User form. | ||
| Submitter License User | Can submit new requests (e.g., incidents, service requests) via the self-service portal; limited to submission forms only. | Cannot view or modify records after submission; no access to full ITSM console. | Submitter accounts are typically used for end-user/requester personas; they do not count against full ITSM named-user seats but do require a valid People record. | ||
| Administrator | Full access to AR System Administration Console, user management, form configuration, workflow, and all ITSM modules. | The built-in 'Demo' and 'Admin' accounts cannot be deleted; the Admin account should be secured immediately after deployment. | |||
| Support Staff (Functional Role) | Access to ITSM modules (Incident, Change, Problem, etc.) as defined by assigned functional roles and permission groups. | Cannot access AR System Administration Console unless explicitly granted administrator privilege. | Functional roles (e.g., Incident Master, Change Coordinator) must be assigned individually per module; there is no single 'agent' role that grants access to all modules. |
Permission model
- Model type: hybrid
- Description: BMC Helix ITSM uses a layered permission model built on the AR System platform. Access is controlled by: (1) AR System Groups (permission groups assigned to forms and fields), (2) Functional Roles (ITSM-specific roles such as Incident Master, Change Coordinator, Asset Manager), and (3) Application Permissions (module-level access flags on the People record). Administrators can create custom permission groups and assign them to forms and fields at a granular level.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Field-level and form-level permissions are configurable via AR System permission groups. Functional roles control ITSM workflow actions. Both can be customized by administrators.
How to add users
- Log in to the AR System Mid Tier or Helix Portal with an Administrator account.
- Navigate to AR System Administration Console → User Management, or open the 'People' form in ITSM (Remedy ITSM → Foundation → People).
- Click 'New' to create a new People record. Enter required fields: First Name, Last Name, Login ID, and Email Address.
- Set the License Type (Fixed, Floating, Read, or Submitter) on the User form in AR System Administration Console.
- Assign the appropriate Permission Groups under the User record's 'Groups' tab.
- Assign ITSM Functional Roles (e.g., Incident Master, Change Coordinator) on the People record under the 'ITSM Roles' tab.
- Set a temporary password or configure SSO/LDAP authentication as appropriate.
- Save the record. The user can now log in based on their assigned license and permissions.
Required fields: First Name, Last Name, Login ID, License Type, Email Address
Watch out for:
- A People record (in ITSM) and a User record (in AR System) are separate but linked; creating one does not automatically create the other in all configurations.
- Login IDs are case-sensitive and must be unique across the AR System instance.
- Assigning a Fixed license type to a user immediately consumes a named seat from the license pool, even if the user has never logged in.
- Functional roles must be assigned per ITSM module; there is no bulk 'grant all ITSM access' option.
- In Helix SaaS deployments, some user management tasks may be performed through the Helix Portal rather than the AR System Administration Console.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | AR System Administration Console → User Management → Import Users (CSV import via the Data Management Tool or AR System Import utility) |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Not documented |
How to remove or deactivate users
- Can delete users: Yes
- 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.
- Log in to the AR System Administration Console with an Administrator account.
- Navigate to User Management and locate the user by Login ID or name.
- Open the User record and change the 'Status' field from 'Current' to 'Inactive'.
- Save the record. The user will be immediately prevented from logging in.
- Optionally, update the corresponding People record in ITSM to reflect the employment status change (e.g., set 'VIP' or 'Status' fields as appropriate for your organization's process).
| Data impact | Behavior |
|---|---|
| Owned records | Records (incidents, changes, tasks, etc.) previously owned or assigned to the deactivated user remain intact and retain the user's Login ID as the assignee. Reassignment must be done manually or via workflow. |
| Shared content | Shared views, saved searches, and console preferences associated with the user remain in the system after deactivation. |
| Integrations | API integrations or automation rules using the deactivated user's credentials will fail authentication. Service account credentials should be rotated before deactivation. |
| License freed | Setting a user to 'Inactive' status releases the license seat and makes it available for reassignment to a new user. |
Watch out for:
- Deactivating a user does not automatically reassign open tickets; administrators must manually reassign or use workflow automation.
- If the user is the sole member of a support group, deactivation may cause routing failures for new tickets assigned to that group.
- In LDAP/AD-integrated environments, disabling the AD account does not automatically deactivate the AR System user; both must be updated.
- Deleting a User record while associated People and ticket records exist can cause referential integrity issues; deactivation is strongly preferred.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Fixed (Named) License | Dedicated named-user access; not subject to concurrent limits; full ITSM application access. | ~$115/user/month (custom enterprise pricing) |
| Floating (Concurrent) License | Shared pool of concurrent sessions; user can log in when a slot is available; session released on logout. | |
| Read License | Read-only access to AR System forms and ITSM records. | |
| Submitter License | Submit-only access for end users/requesters via self-service portal. |
- Where to check usage: AR System Administration Console → License Management → View License Usage (shows current fixed and floating seat consumption in real time)
- How to identify unused seats: AR System Administration Console → License Management provides a report of last login dates per user. Users with no recent login activity can be identified and deactivated to free fixed seats.
- Billing notes: BMC Helix ITSM is sold under custom enterprise contracts. Pricing is not publicly listed for most license types. License counts are enforced at the platform level; exceeding purchased seat counts will prevent additional users from logging in. License true-ups are typically handled at contract renewal.
The cost of manual management
Adding a single agent means navigating the AR System Administration Console, creating or linking a People record, setting a license type, assigning permission groups, and then repeating functional role assignment for each ITSM module (Incident, Change, Problem, Asset) individually - there is no bulk-grant option.
Assigning a Fixed license type immediately consumes a named seat from the pool, even before the user logs in for the first time. In LDAP/AD-integrated environments, disabling an account in Active Directory does not automatically deactivate the AR System user; both systems must be updated separately, which is a documented source of orphaned active accounts.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Remedy is the right choice when an organization needs a deeply configurable, enterprise-grade ITSM platform with field-level and form-level permission granularity across multiple modules. The layered model - AR System Groups, Functional Roles, and Application Permissions - gives administrators precise control, but that same layering means every access change touches multiple configuration surfaces.
Teams with low IT admin headcount or high employee turnover should weigh the ongoing operational cost of manual provisioning and deprovisioning against the platform's capabilities.
Bottom line
BMC Remedy (Helix ITSM) delivers enterprise-grade access control through a hybrid permission model, but its lack of native SCIM and its dual-record architecture mean that every app relying on accurate Remedy identity data depends entirely on manual administrator action or custom API integration to stay current.
Deactivation is the recommended offboarding path over deletion, as removing a User record while associated ticket and People records exist can cause referential integrity issues.
Organizations running Helix SaaS should also confirm which user management tasks have migrated to the Helix Portal, as the administration surface differs from on-premise AR System deployments.
Automate BMC Remedy (Helix ITSM) 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.
