Summary and recommendation
Atlassian Jira Service Management 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.
Atlassian Jira Service Management separates users into two distinct types: licensed agents and free portal customers. Agents consume a paid seat the moment they are granted product access in admin.atlassian.com - before they ever log in.
Customers access only the request portal and never consume a billable seat, but promoting a customer to agent immediately triggers seat consumption. Unlike every app that bundles SSO and SCIM into higher tiers, JSM requires a separate Atlassian Guard Standard subscription to unlock automated provisioning.
Quick facts
| Admin console path | admin.atlassian.com → select Organization → Directory → Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Atlassian Guard Standard |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Agent | Can view and work on all issues in assigned service projects, access queues, SLAs, reports, and the agent view. Can be granted project-role-based permissions (Service Project Team, Service Project Administrator). Counts against licensed seats. | Cannot access other Jira products unless separately licensed. Cannot manage organization-level settings unless also granted site-admin. | Free (up to 3 agents), Standard, Premium, or Enterprise | Billable licensed seat. Free: $0 up to 3 agents. Standard: ~$23.80–$25/agent/month (10-user tier, billed monthly). Premium: ~$53.30–$57.30/agent/month (10-user tier, billed monthly). Enterprise: custom pricing. | Every agent added to a service project consumes a JSM license seat regardless of how active they are. Removing an agent from all service projects frees the seat only if they are also removed from the product in admin.atlassian.com. |
| Customer (Portal User) | Can raise and track requests via the customer portal or email. Can view only their own requests (or all requests in a project if 'Anyone can view all requests' is enabled). Cannot access the agent view or internal Jira issues. | Cannot work on issues, access queues, view SLAs, or access any Jira product interface beyond the portal. | All plans including Free | Free – customers do not consume agent license seats. | Customers can be added without an Atlassian account if 'Anyone can send requests' is enabled. If account creation is required, customers receive an Atlassian account but still do not consume a paid seat. Confusion arises when a customer is later promoted to agent-they then consume a seat. |
| Site Administrator | Full administrative access to the Atlassian site: manage users, products, billing, and site-level settings. Can grant/revoke product access and project roles. | Cannot manage organization-level identity policies (SSO, SCIM, domain claiming) unless also granted Organization Admin role. | All plans | Consumes an agent seat if also added to a JSM service project as an agent; otherwise no additional seat cost for the admin role itself. | Site Admin is a site-level role distinct from Organization Admin. Granting Site Admin does not automatically grant Organization Admin and vice versa. |
| Organization Admin | Manages the Atlassian organization: domain claiming, authentication policies, SCIM provisioning (requires Atlassian Guard), user directory, and all sites under the org. | Cannot perform project-level actions in JSM unless also added as an agent or site admin on a specific site. | All plans; SCIM and SSO features require Atlassian Guard Standard subscription | No additional seat cost for the org-admin role itself. | SCIM provisioning and SSO enforcement require a separate Atlassian Guard Standard subscription on top of JSM plan costs. |
| Project Administrator (Service Project) | Can manage a specific service project's settings, queues, SLAs, request types, and team members within that project. Assigned via the 'Service Project Administrator' project role. | Cannot manage other projects or site-level settings unless granted additional roles. | All plans | Must be a licensed agent to hold this role; consumes an agent seat. | Project Administrator role is project-scoped. A user must still be an agent (licensed) to be assigned this role. |
Permission model
- Model type: hybrid
- Description: JSM uses a layered permission model combining global permissions (site-level, e.g., 'Jira Administrators'), project roles (e.g., 'Service Project Team', 'Service Project Administrator', 'Service Project Customer'), and issue-level security schemes. Global permissions are managed in Jira settings; project roles are assigned per project. Permission schemes map project roles to specific actions (e.g., 'Work on Issues', 'Manage Sprints'). Customers are controlled separately via portal access settings rather than standard Jira permission schemes.
- Custom roles: Yes
- Custom roles plan: All plans (custom project roles can be created in Jira settings by site admins)
- Granularity: Project-level and issue-level. Permissions can be granted to individual users, groups, project roles, or 'Any logged-in user'. Issue security schemes allow field-level visibility restrictions per issue.
How to add users
- To add an agent: Navigate to admin.atlassian.com → select your Organization → select the Site → click 'Jira Service Management' under Products.
- Click 'Add users' and enter the user's email address.
- Assign the user the 'Jira Service Management' product role (this grants agent access and consumes a seat).
- Optionally, navigate to the specific JSM project → Project settings → People → Add the user to the 'Service Project Team' or 'Service Project Administrator' project role.
- To add a customer: In the JSM project, go to Project settings → Customer permissions → invite customers by email, or allow customers to self-register via the portal.
Required fields: Email address (for agent invitation), Product role selection (agent vs. no product access)
Watch out for:
- Adding a user to the Jira Service Management product in admin.atlassian.com immediately consumes a billable seat even before they log in.
- Users invited as customers do not consume agent seats, but if they are later granted product access they will.
- If the user's email domain is not yet verified/claimed, they may not be subject to org-level authentication policies until domain is claimed.
- On Free plan, adding a 4th agent will prompt an upgrade to a paid plan.
- Users must accept the invitation email before they can log in; pending invitations still count toward seat usage on some plan tiers.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | admin.atlassian.com → Organization → Directory → Users → Invite users → 'Import users from CSV' |
| Domain whitelisting | Yes | Automatic domain-based user add |
| IdP provisioning | Yes | Atlassian Guard Standard (separate subscription required on top of JSM plan) |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Atlassian managed accounts cannot be permanently deleted by an organization admin. Admins can deactivate (suspend) a managed account, which revokes product access and frees the license seat. The account record and all associated data (issues, comments, audit logs) are retained. Atlassian accounts that are not managed (i.e., the user's domain is not claimed by the org) can only be deactivated from product access, not deleted by the admin.
- Navigate to admin.atlassian.com → select your Organization → Directory → Users.
- Search for the user by name or email.
- Click the user's name to open their profile.
- Click 'Deactivate account' (for managed accounts) or remove product access by going to the 'Product access' tab and removing JSM product role.
- Confirm the deactivation. The user is immediately logged out of all active sessions.
- Alternatively, to only remove agent seat without full deactivation: go to admin.atlassian.com → Site → Jira Service Management → Users → remove the JSM product role from the user.
| Data impact | Behavior |
|---|---|
| Owned records | Issues, requests, and comments created by the deactivated user are retained and remain visible. The user's display name appears as the reporter/assignee but the account is marked inactive. |
| Shared content | Dashboards, filters, and project configurations created by the user remain in place. Other users can still access shared content. |
| Integrations | API tokens associated with the deactivated account are invalidated immediately. Any integrations or automation rules using that user's API token will break and must be reconfigured with a different account's token. |
| License freed | Deactivating the account or removing the JSM product role frees the agent seat immediately. The seat becomes available for reassignment in the next billing cycle or immediately depending on plan. |
Watch out for:
- Removing a user from a project role does not remove their product access or free their seat; the product role must be removed in admin.atlassian.com.
- API tokens tied to a deactivated account are immediately revoked, which can silently break integrations and automation.
- Deactivated users still appear in historical issue data and audit logs, which is intentional for compliance but can cause confusion.
- If a user is a member of a group that grants product access, removing the product role directly may be overridden by group membership; the user must also be removed from the group.
- On Atlassian Guard-managed orgs, deactivation via SCIM (IdP-side disable) is the recommended method to ensure consistent deprovisioning across all Atlassian products.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Agent (Licensed User) | Full access to JSM agent view, queues, SLAs, reports, and service project management. Required for anyone working on issues. | Free: $0 (max 3 agents). Standard: ~$23.80–$25/agent/month at 10-user tier (billed monthly); decreases with scale. Premium: ~$53.30–$57.30/agent/month at 10-user tier (billed monthly). Enterprise: custom. |
| Customer (Portal User) | Access to the customer portal to raise and track requests only. | Free on all plans; does not consume a paid seat. |
| Atlassian Guard Standard (add-on) | SCIM provisioning, SSO enforcement, authentication policies, audit logs, and API token controls across the organization. | Separate subscription; pricing not bundled with JSM. Required for automated user provisioning/deprovisioning via IdP. |
- Where to check usage: admin.atlassian.com → select Organization → select Site → Jira Service Management → 'Users' tab shows current agent count and seat usage. Billing details at admin.atlassian.com → Billing.
- How to identify unused seats: admin.atlassian.com → Organization → Directory → Users → filter by 'Last active' date to identify users who have not logged in recently. No built-in 'unused seat' report; admins must manually review last-active dates and cross-reference with product access.
- Billing notes: JSM is billed per agent (licensed user); customers are free and unlimited. Billing is based on the number of users with product access at the time of billing, not peak usage. Annual billing offers a discount over monthly. Atlassian Guard Standard is a separate line-item subscription. Marketplace app licenses are billed separately and typically priced per user per month. Per-agent cost tiers decrease as agent count increases (volume pricing).
The cost of manual management
Seat management in JSM requires two separate actions: removing a user from a project role does not free their license - the product role must also be removed in admin.atlassian.com. There is no built-in report for unused seats; admins must manually filter by last-active date in the Directory view.
Automated provisioning via SCIM requires a separate Atlassian Guard Standard subscription on top of the JSM plan, adding a distinct cost line that catches teams off guard.
What IT admins are saying
The most consistent friction reported by admins centers on three areas. First, the Guard Standard requirement for SCIM and SSO surprises teams who expect these features to be included in higher JSM tiers.
Second, the two-step removal process - project role plus product access - causes recurring seat-leak confusion.
Third, API tokens are tied to individual user accounts and expire after one year with no programmatic renewal; deactivating a user immediately revokes their token, silently breaking any integrations or automations that depended on it.
Common complaints:
- Atlassian Guard Standard is a separate paid subscription required for SCIM and SSO, adding significant cost on top of JSM plan fees.
- No native permanent user deletion; deactivation only, which can clutter user directories over time.
- Removing a user from a project role does not free their license seat; admins must also remove product access in admin.atlassian.com, causing confusion.
- API tokens expire after 1 year and are tied to individual user accounts; deactivating a user immediately breaks any integrations using that token with no grace period.
- Customer role complexity: distinguishing between portal-only customers and licensed agents is confusing, especially when customers need to be promoted to agents.
- No built-in report to identify inactive or unused agent seats; admins must manually review last-active dates.
- Group-based product access can silently re-grant access to a user whose direct product role was removed, making deprovisioning unreliable without also managing group membership.
- Pending invitations may count toward seat limits depending on plan tier, consuming seats before users have logged in.
The decision
JSM's permission model is hybrid: global permissions sit at the site level, project roles are assigned per project, and customers are governed by separate portal access settings entirely outside standard Jira permission schemes.
The Organization Admin and Site Admin roles are distinct and do not inherit from each other - a common source of access gaps. Every app your team connects to JSM inherits the agent/customer distinction, which means access reviews must account for both licensed and unlicensed account types separately.
Custom project roles are available on all plans, but a user must hold a licensed agent seat before any project-scoped role can be assigned.
Bottom line
Jira Service Management gives teams a capable ITSM platform with granular role controls, but its access management carries real operational cost.
The agent/customer distinction is meaningful for billing but easy to misconfigure, and every app connected to JSM via API tokens inherits the one-year expiry risk.
Teams managing more than a handful of agents will feel the absence of automated provisioning acutely - and should factor the Atlassian Guard Standard subscription cost into any build-vs-buy calculation before committing to a manual workflow.
Automate Atlassian Jira Service Management 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.
