Keeping track of the deleted records
Our applications replicate the complete data from the source. Some source systems have a "State" attribute to track the health or lifecycle of the asset. For example:
Source | Object Type | Attribute | Possible Values |
|---|---|---|---|
Azure AD | Users | Account Enabled | True / False |
Intune | Managed Devices | Device Registration State | notRegistered, registered, revoked, keyConflict, approvalPending, certificateReset, notRegisteredPendingEnrollment, unknown |
Datadog | Hosts | Is muted | True / False |
On the other hand, if a resource is deleted from the source, then there is no information coming from the source for that record. We recommend using the features of Assets for this purpose.
Instructions
Go to Object Schema Configuration.
Select the “Statuses” tab.
Click “Create a status”
Call it “Deleted” and select the red category (inactive).
 |
|---|
Go back to Object Schema.
Select the object type you would like to modify.
Select the Attributes tab.
Add a new attribute for “Source State” with a type of Status.
|
|---|
Go to Object Schema Configuration again.
Select the import tab.
Select “Edit Mapping” for the import configuration.
Select edit object type mapping for the Object Type that you would like to update.
|
|---|
Change the setting for “Missing objects” to “Update”. Select the “Source State” attribute. And write “Deleted” for the new value. Set the Threshold Number to 3. This means that if a record is not found three times, it will be marked as “Deleted” during the fourth import.
|
|---|
It is important to note that if you set the “Missing objects” to “Remove”, then Assets will remove the objects if they are not found in the source data. This is risky and we don’t recommend it for the following reasons:
1- Assets doesn’t have a trashcan/rollback/recover feature. When an object is deleted, then you can not recover it. It will be gone including the references, or the linked issues.
2- You will also lose the history of the object. In case you have audits, you won’t be able to show the activity history of an asset.
Another critical configuration parameter is the threshold number. If you set it to 0, this means Assets will delete the missing objects immediately. This is also not recommended. When the import process doesn’t work properly due to a service outage at the source, or Assets, then you may lose all your objects. We recommend keeping this value at least 3 if you have daily schedule, or 36 if you have hourly schedule set. This will give you time to check the import status and stop the data flow if necessary before all data is deleted.
If you really need to delete records, we recommend deleting them manually once a month (or another period you prefer).
From now on you can follow the imports and check if the records are being marked as Deleted.
Example AQL:
"Source State" = "Deleted"
|
|---|
We recommend testing the new configuration on your sandbox first and validating that it works as you expected.
It is important to note that these settings can be overwritten because of a known bug in JSM Assets.
https://jira.atlassian.com/browse/JSDCLOUD-12603
You need to check these settings every time you update the data model.
Another important bug reported by Atlassian after the Assets rearchitecture is as follows:
Please review all the bugs reported in the list and vote if you are impacted. This will help Atlassian to prioritize the fixes.
Related articles