Atlassian Opsgenie User Management Guide

• Model type: hybrid
• Description: Opsgenie uses a two-layer permission model. At the account level, four default roles (Owner, Admin, Default User, Stakeholder) control global access. Custom User Roles extend or restrict the Default User role by granting or revoking specific named rights (e.g., alert-update-priority, logs-page-access). At the team level, two predefined team roles (Team Admin, Team Member) apply scoped permissions within a team, and custom team roles can be created with granular team-specific rights.
• Custom roles: Yes
• Custom roles plan: Standard and Enterprise plans only
• Granularity: Per-right grant/revoke on a named list of rights (e.g., alert-acknowledge, alert-close, alert-escalate, alert-update-priority, logs-page-access, maintenance-edit, edit-profile, etc.). Custom roles must extend either the 'user' or another base role. Team-level custom roles are configured separately under Teams > Roles.

1. Log in as Owner, Admin, or a user with Edit Configuration rights.
2. Navigate to Settings (gear icon) > Users.
3. Click the 'Add User' button in the top-right corner of the users list.
4. Enter the user's email address in the 'E-mail' field (used as username; must be unique across all Opsgenie accounts; max 100 characters).
5. Enter the user's full name in the 'Name' field.
6. Select the user's role from the 'Select Role' dropdown (Owner role can only be assigned by an existing Owner).
7. Click 'Add' to create the user and send an invitation email.
8. User must click the 'Activate Your Account' link in the invitation email within 2 days to activate their account.
9. If the invitation expires or is not received, hover over the user's row in the Users page under the 'Status' column and click 'Send Invitation' to resend.

Required fields: Email address (unique across all Opsgenie accounts, max 100 characters), Full name, Role selection

Watch out for:

• Invitation links expire after 2 days; admin must manually resend.
• Email address serves as the username and cannot be a duplicate across any Opsgenie account globally.
• Only account owners can assign the Owner role to another user.
• If all license seats are consumed, adding a new user will fail silently or with an error; the Owner must increase the seat count under Settings > Subscription (Billing) before adding more users.
• Opsgenie does not automatically increase the license count when the seat limit is reached.
• Only owners, admins, or users with Edit Configuration rights can access the Users page to add 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.

1. For JSM-merged instances only: Remove the user's JSM license in Atlassian admin (admin.atlassian.com). This triggers an Opsgenie account deactivation. The user has 14 days before permanent deletion.
2. For standalone Opsgenie: No deactivation state exists. Proceed directly to deletion.

Watch out for:

• Deletion is blocked if the user is currently part of any escalation or on-call schedule. The error message lists the blocking configurations; admin must remove the user from each before retrying deletion.
• The sole Owner of an account cannot be deleted. At least one Owner must remain at all times.
• Account admins cannot delete users with the Owner role; only account owners can delete other owners.
• In JSM-merged instances, deleting a user in Opsgenie removes their JSM license and vice versa - cross-product impact is immediate.
• Deleting an Atlassian account via admin.atlassian.com does NOT automatically delete the associated Opsgenie account; Opsgenie deletion must be performed separately.
• If users are provisioned via an IdP (SCIM), the user must be removed from the IdP first; otherwise the Atlassian account will be recreated on the next sync.

• Where to check usage: Settings (gear icon) > Subscription (under Billing in the left-hand menu). Displays current license count and active user count. Only accessible by account Owners.
• How to identify unused seats: Use the Users page search/filter to identify users with 'Pending' invitation status (never activated) or use the User API (GET https://api.opsgenie.com/v2/users) to list all users and cross-reference with last-login or activity data. The Lamp CLI tool (opsgenie-lamp exportUsers) can export users to CSV for offline analysis.
• Billing notes: New Opsgenie sales ended June 4, 2025. Existing customers must migrate to Jira Service Management by April 5, 2027. Billing is per active responder seat; stakeholder seats are free. Only the account Owner can view or modify subscription and billing settings - no read-only billing access exists for other roles. If the seat limit is reached, new users cannot be added until the Owner increases the license count under Settings > Subscription. SCIM provisioning requires an additional Atlassian Guard subscription (~$4/user/month) on top of the Opsgenie plan cost.

Every app has a ceiling where manual provisioning breaks down, and Opsgenie's is unusually low. Invitation links expire after 2 days, requiring admin follow-up for any user who misses the window.

Seat limits do not auto-expand - when the limit is hit, new user additions fail, and only the account Owner can increase the count under Settings > Subscription.

Deletion is the only removal action in standalone accounts; there is no suspend or deactivate state, so offboarding requires auditing and clearing every on-call schedule and escalation policy that references the user before the delete will succeed.

In JSM-merged instances, deleting a user in Opsgenie simultaneously revokes their JSM license, creating unintended cross-product access removal with no grace period.

The absence of a native deactivate or suspend state is the most-cited friction point in the Opsgenie community. Admins working in standalone accounts must permanently delete users, which surfaces gaps in on-call history display despite the Deleted Users tab.

A long-standing feature request (OPSGENIE-1428) to delegate user management to custom roles remains unresolved. Billing and subscription visibility is locked to the Owner role exclusively - Admins have no read-only access to seat counts or usage data.

The Stakeholder role, which is free and does not consume a paid seat, is unavailable in any Opsgenie instance subordinated to a JSM subscription, requiring a separate standalone account and independent billing to access it.

Common complaints:

• No native deactivate/suspend state for users in standalone Opsgenie; the only option is permanent deletion, which removes the user from on-call history display (partially addressed by the Deleted Users tab).
• User management (add/edit/delete users) is restricted to Owner and Admin roles only; there is no way to delegate user management to a custom role, despite an open feature request (OPSGENIE-1428).
• Billing and subscription visibility is restricted exclusively to the Owner role; no read-only billing access exists for Admins or other roles.
• Stakeholder role is unavailable in Opsgenie instances subordinated to a JSM subscription, regardless of JSM plan tier; accessing Stakeholders requires splitting into a standalone Opsgenie subscription with separate billing.
• Opsgenie does not automatically increase the license seat count when the limit is reached; the Owner must manually increase seats under Settings > Subscription, and failed additions may occur silently.
• Deleting a user in a JSM-merged instance revokes their JSM license simultaneously, creating unintended cross-product access removal.
• UI inconsistency reported by users: the Opsgenie settings interface differs between standalone and Atlassian-workspace-merged accounts, causing confusion when following official documentation screenshots.
• Multiple subscriptions required for full feature access: standalone Opsgenie plan + Atlassian Guard for SCIM, with SSO as a prerequisite.
• End-of-life announcement (April 5, 2027) creates migration urgency; new sales ended June 4, 2025.
• Email address changes made in an Atlassian account are not automatically reflected in the associated Opsgenie account, requiring manual reconciliation.

Manual management is viable for small, stable teams on the Essentials or Standard plan where on-call rosters change infrequently. It becomes operationally risky at scale: every app that grows beyond a handful of responders will accumulate stale accounts that require manual schedule audits before removal.

Teams on Enterprise with an existing IdP should evaluate SCIM provisioning - it requires an additional Atlassian Guard subscription (~$4/user/month) and SSO configuration as a prerequisite, but it eliminates invitation expiry, seat-limit surprises, and the manual offboarding audit burden.

Given the April 2027 end-of-life deadline, any significant investment in Opsgenie-specific provisioning workflows should be weighed against the migration path to Jira Service Management.

Bottom line

Opsgenie's manual user management is functional but brittle: no suspend state, no billing visibility below Owner level, no delegation of user management to custom roles, and a hard dependency on the Owner for seat increases.

For teams with low churn and fewer than 20–30 users, the admin console is sufficient. For larger or faster-moving teams, the operational cost of manual provisioning - expired invitations, blocked deletions, and cross-product license side effects in JSM-merged instances - accumulates quickly.

The platform's April 2027 end-of-life adds urgency to any decision about how much process to build around it.