Okta to JSM Assets

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

  1. In Jira, go to Manage your apps.

  2. Open OnLink.

  3. Select Connections.

  4. Click Add System.

  5. Choose Idm/Device Assets Sources.

  6. Configure and save the Okta connection.

3. Create the Assets import configuration

  1. After the Okta connection is established, create an Assets import configuration.

  2. Follow the detailed setup instructions here: Assets import setup guide.

  3. 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=Department

Search 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=500

Data 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=User

Devices 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,apps

In 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/groups

Apps

key:id=App ID map:label=App Name config:data_source=/api/v1/apps

Other 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

Key / Map / Config

Meaning

Example / Notes

key:id=WorkerID

Defines the unique identifier for the Assets object. OnLink uses this value to update existing records.

Use a stable Okta field such as id.

map:profile.email=User

Maps the Okta profile email field to an Assets attribute named User.

The target attribute can be a User attribute.

map:profile.email=JiraUser

Maps the user's email address to a Jira user attribute.

OnLink looks up the Atlassian user object based on the email address.

config:search

Filters records returned by Okta.

Example: config:search=status eq "STAGED"

config:page_size=500

Controls the number of records retrieved per page.

Defaults to 200. Maximum is 500.

config:data_source

Changes the Okta API endpoint used for the import.

Users are the default. Example: config:data_source=/api/v1/devices?limit=200&expand=userSummary

config:section=roles,groups,apps

Includes additional user resource sections.

Use with mappings such as map:roles=Roles|Name=${roles}, map:groups=Groups|Name=${groups}, and map:apps=Apps|Name=${apps}.

7. Test and run the import

OnLink processes data in two steps: Get Data and Import Data.

  1. Click Get Data to retrieve records from Okta.

  2. Open the job logs and wait for this message: No more pending records. Data will be imported on next Import run.

  3. Click Import to import the staged data into JSM Assets.

  4. 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.