Summary and recommendation
VictorOps 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.
VictorOps - now branded Splunk On-Call - is an incident management and on-call scheduling platform sold as an add-on to Splunk Observability Cloud.
Every app in your incident stack requires accurate user rosters to function reliably, and VictorOps is no exception: stale memberships directly break on-call coverage.
User management lives at Settings → Users inside the web portal (https://portal.victorops.com/dash), and only Global Admins can invite, role-change, or deactivate users.
Quick facts
| Admin console path | Settings → Users (within the VictorOps / Splunk On-Call web portal) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Global Admin | Full access to all organization settings, user management, billing, integrations, escalation policies, teams, and on-call schedules. | Only Global Admins can invite new users, change roles, and deactivate users. At least one Global Admin must remain active on the account. | |||
| Alert Admin | Can manage escalation policies, routing keys, teams, and on-call schedules. Cannot manage billing or change user roles. | Cannot access billing settings or promote/demote other users. | |||
| User | Can acknowledge and resolve incidents, manage personal on-call schedule and contact methods, and view team information. | Cannot modify organization-level settings, manage other users, or access billing. | $5/user/month (add-on to Splunk Observability Cloud, billed annually) | All billable seats are counted at the User level regardless of role assignment. |
Permission model
- Model type: role-based
- Description: VictorOps uses a fixed three-tier role model: Global Admin, Alert Admin, and User. Roles are assigned per user across the entire organization; there are no team-scoped or resource-scoped permission overrides.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Organization-wide role assignment only; no per-team or per-resource permission granularity.
How to add users
- Log in to the VictorOps portal at https://portal.victorops.com/dash.
- Navigate to Settings → Users.
- Click 'Invite User'.
- Enter the user's email address.
- Select the desired role (Global Admin, Alert Admin, or User).
- Click 'Send Invitation'. The invitee receives an email to set their password and complete registration.
Required fields: Email address, Role
Watch out for:
- Invitations expire; if the user does not accept within the expiry window, the invitation must be resent.
- The inviting account must have Global Admin privileges.
- Users are counted as billable seats as soon as they accept the invitation, not when the invitation is sent.
- Username/email cannot be changed after account creation; a new user record must be created if the email changes.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (SSO prerequisite required; SCIM provisioning requires Enterprise tier) |
How to remove or deactivate users
- Can delete users: Verify in tenant
- 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 VictorOps portal at https://portal.victorops.com/dash.
- Navigate to Settings → Users.
- Locate the user to be deactivated.
- Click the user's name to open their profile.
- Click 'Deactivate User' and confirm the action.
| Data impact | Behavior |
|---|---|
| Owned records | Incident history and alert records associated with the deactivated user are retained and remain visible in the audit trail. |
| Shared content | The user is automatically removed from any teams, on-call schedules, and escalation policies upon deactivation. |
| Integrations | Any API tokens or personal integrations tied to the deactivated user will no longer function. |
| License freed | Deactivating a user frees the billable seat; the seat count is reduced for the next billing cycle. |
Watch out for:
- Deactivating the only Global Admin on an account is blocked; another Global Admin must be assigned first.
- Removing a user from on-call schedules and escalation policies is automatic upon deactivation, but admins should verify coverage gaps before deactivating.
- Reactivating a previously deactivated user restores their account and consumes a billable seat again.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| On-Call User Seat | Full access to incident management, on-call scheduling, mobile app, and integrations. Role (Global Admin, Alert Admin, User) is assigned separately from seat type. | $5/user/month billed annually (add-on to Splunk Observability Cloud) |
- Where to check usage: Settings → Users (shows active vs. deactivated users and total seat count)
- How to identify unused seats: Review the 'Last Login' column in Settings → Users to identify users who have not logged in recently. Deactivated users are listed separately and do not consume seats.
- Billing notes: Splunk On-Call (VictorOps) is sold as an add-on to Splunk Observability Cloud. The base On-Call add-on starts at $5/user/month billed annually. Enterprise pricing is custom. A 14-day free trial is available. Seat count is based on active (non-deactivated) users.
The cost of manual management
In VictorOps, invitations expire silently, so a missed follow-up means a new hire misses on-call coverage until an admin re-sends. Deactivated users stay visible in the roster, and the only way to spot unused seats is to manually scan the Last Login column in Settings → Users.
Username and email are immutable after account creation - if an employee's email changes, the only path forward is deactivating the old record and creating a new one from scratch.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Every app your team depends on for on-call coverage carries real operational risk when user lifecycle management is fully manual, and VictorOps is a clear example of that tradeoff.
The workflow is manageable for small, stable teams but becomes a liability at scale: no bulk operations, immutable usernames, and a flat three-role model all compound as headcount grows. Teams expecting frequent roster changes or multi-team permission structures should factor in the cost of working around these constraints before committing.
Bottom line
VictorOps covers the core incident-management use case well, but its user management is deliberately minimal. A deactivated user is removed from on-call schedules automatically, but escalation policy gaps require a separate manual audit - a step that is easy to skip under pressure.
For organizations on the Enterprise plan with SSO already in place, IdP-driven SCIM provisioning is the most reliable path to keeping the roster accurate without per-user admin effort.
Automate VictorOps 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.
