In this guide, we will discuss two different ways of configuring the external identifier of the import settings for JSM Assets.
Current Status
Our applications are designed leveraging Atlassian’s API guidelines. They expect the Atlassian expects complete control of the schema to be in the power of our applications. This requires the object schema, object types, attributes, relations, and their mapping to be managed by our applications.
...
Source | Object Type | Identifier |
|---|---|---|
Entra ID | Users | User ID |
Intune | Managed Devices | ID |
Jamf | Computers | Computer ID |
Current Experience:
Most source systems don’t provide information when a record is deleted. Therefore, we recommend configuring the Assets to recognize missing records (objects). Please refer to the documentation for more details: Keeping track of the deleted records
The default behavior example in this case is as follows:
In At the source (i.e., Intune/Jamf, etc.), there is a definition of a laptop is defined.
The record is imported into Assets with the help of our application.
An employee leaves the organization, and the laptop is formatted/wiped/reset by the source (i.e., Intune/Jamf, etc.)
The laptop record has been deleted from Intune/Jamfthe source.
A new laptop record is created in Intune/Jamfat the source with a new ID and the same Serial Number.
With the next import, a new object is created for the device since the ID is different for the new record.
As a result, there will be 2 records with the same serial number. One of them will be new and the other one will be marked as deleted.However, this behaviour is “deleted” if the settings are performed as explained on the guide.
Alternative Way:
Sometimes, organizations would like to see only one device record in JSM Assets for each serial number. Or, one employee record for an employee id/number. This is also possible with the help of Assets Import Mapping configuration.
Default Identifier (ID) | Custom Identifier (Serial Number, Employee ID, etc.) | |
|---|---|---|
Pros | Historical data and current data in the same Object Type. Possible to export historical activities to excel for records or create reports for audit purposes. Upcoming schema versions will be using the same setting. Upgrades will be seamless for our applications. | One record gets updated continiously (for a device or employee, etc.) |
Cons | There will be multiple records for a deleted and recreated record (can be perceived as duplicate records). To view the current status, a filter needs to be used in custom fields, automation or object view. Example AQL: | Not possible to export historical activities to excel for records or create reports for audit purposes. To view a record history, users need to review each record one by one and check the activity tab. Upcoming schema versions will be using the default settings. After each upgrade Jira Admins need to update the identifier again manually. It is important to note all manual changes in a change log so that this important item is not forgotten. This could result creation of dublicate records in JSM Assets. |
In your case, you may change it to Serial Number.
...