Okta to JSM Assets
Import Okta Data into JSM Assets with OnLink
Use this guide to import users, applications, groups, roles, devices, and other Okta attributes into Jira Service Management (JSM) Assets using OnLink.
1. Prerequisites
Access to OnLink from Jira Manage your apps.
Okta API access with permission to read the objects you want to import.
A JSM Assets schema with object types and attributes prepared for the imported data.
The OnLink Assets import configuration instructions: Assets import setup guide.
Okta field reference: Okta Users API.
2. Create the Okta connection in OnLink
In Jira, go to Manage your apps.
Open OnLink.
Select Connections.
Click Add System.
Choose Idm/Device Assets Sources.
Configure and save the Okta connection.
3. Create the Assets import configuration
After the Okta connection is established, create an Assets import configuration.
Follow the detailed setup instructions here: Assets import setup guide.
Return to OnLink from Manage your apps to configure the field-level mapping.
4. Configure field-level mappings
Mappings define how values returned by Okta APIs are written into JSM Assets attributes. Any field available in the Okta Users API response can be mapped to an Assets attribute.
Use
key:to define the unique identifier that OnLink uses to update existing Assets records.Use
map:to map an Okta response field to an Assets attribute.Use
config:to control import behavior, such as search filters, page size, data source, or additional sections.
5. Mapping examples
User import: basic profile fields
key:id=WorkerID
map:profile.email=User
map:profile.firstName=First Name
map:profile.lastName=Last Name
map:profile.managerId=ManagerUserId
map:profile.manager=Manager Name
map:profile.department=DepartmentSearch filters and page size
Use config:search to limit which users are returned from Okta.
config:search=status eq "STAGED"Filter by user type:
config:search=(profile.userType eq "Employee" or profile.userType eq "Contingent Worker")Users with status DEPROVISIONED are omitted by default. To return all required user statuses, use an explicit search query:
config:search=(status eq "ACTIVE" or status eq "DEPROVISIONED" or status eq "PROVISIONED" or status eq "PASSWORD_EXPIRED")Set the page size. The default is 200, and the maximum is 500.
config:page_size=500Data source examples
OnLink calls the Okta Users API by default. Use config:data_source to call another Okta API endpoint.
Users default
# No data_source is required for the default Users API.
key:id=WorkerID
map:profile.email=UserDevices example
key:id=DeviceID
map:profile.displayName=Device Name
map:profile.platform=Device Platform
map:profile.manufacturer=Device Manufacturer
map:profile.model=Device Model
map:profile.osVersion=Device OS Version
map:_embedded.users.0.user.profile.firstName=First Name
map:_embedded.users.0.user.profile.lastName=Last Name
map:_embedded.users.0.user.profile.email=Email
config:data_source=/api/v1/devices?limit=200&expand=userSummary
config:search=status eq "ACTIVE"User resources: roles, groups, and apps
To fetch roles, groups, and apps assigned to users, include the section configuration. This loads role, group, and app names into the respective Assets objects. We recommend to do this as a separate import.
key:id=Username
map:profile.firstName=Firstname
map:profile.lastName=Lastname
map:roles=Roles|Name=${roles}
map:groups=Groups|Name=${groups}
map:apps=Apps|Name=${apps}
config:section=roles,groups,appsIn this model, Groups and Apps point to Okta Groups and Apps objects. Set cardinality to a maximum greater than 0 because each user can have more than one group or app assigned.
Additional objects: Groups and Apps
Use separate import mappings when you want Groups and Apps to exist as their own Assets object types.
Groups
key:id=Group ID
map:profile.name=Group Name
map:profile.description=Group Desc
config:data_source=/api/v1/groupsApps
key:id=App ID
map:label=App Name
config:data_source=/api/v1/appsOther Okta APIs can be mapped in the same way. Any field returned by the selected API can be used in the mapping.
6. Mapping reference
Key / Map / Config | Meaning | Example / Notes |
|---|---|---|
| Defines the unique identifier for the Assets object. OnLink uses this value to update existing records. | Use a stable Okta field such as |
| Maps the Okta profile email field to an Assets attribute named User. | The target attribute can be a User attribute. |
| Maps the user's email address to a Jira user attribute. | OnLink looks up the Atlassian user object based on the email address. |
| Filters records returned by Okta. | Example: |
| Controls the number of records retrieved per page. | Defaults to 200. Maximum is 500. |
| Changes the Okta API endpoint used for the import. | Users are the default. Example: |
| Includes additional user resource sections. | Use with mappings such as |
7. Test and run the import
OnLink processes data in two steps: Get Data and Import Data.
Click Get Data to retrieve records from Okta.
Open the job logs and wait for this message:
No more pending records. Data will be imported on next Import run.Click Import to import the staged data into JSM Assets.
Review the imported Assets objects and confirm that the mapped attributes were populated correctly.
8. Scheduling and automation
For production imports, configure the schedule in the OnLink import configuration. Scheduled production runs are automated based on the cadence you choose.
Use manual Get Data and Import runs to validate mappings before enabling a production schedule.
Monitor job logs after scheduled runs to confirm that data retrieval and import completed successfully.
Update mappings when Okta attributes or JSM Assets attributes change.