How to customize the Object Schema

General Warning:

Deleting a configuration is risky because JSM Assets doesn’t have a rollback, undo, or recovery button.

Having said that, there are changes that you can apply, you better not do, and you shouldn’t do. Here is a summary:

You Can	Better not to	Don’t

You Can	Better not to	Don’t
You can create a new object type when you need. Note: This part will be manual. Our application will not know about this Object Type, and you will not be able to map the incoming data in the import mapping settings. You can add a new attribute with "Object" type and create a reference from the existing object type to your new object type. Note: Since the scheduled import will not map the data, you will need to write an automation rule for creating the relationship. Our application doesn't delete object types or attributes that you manually created. You can create a reference from the new object type to the automatically created object types. Drag the object type and change its place in the object tree. Disable an import mapping for an object type to reduce the number of objects being imported (i.e., Storage objects for Jamf)	Delete an attribute mapping under the Import tab of Object Schema Settings Change the import mapping for a referenced attribute from Advanced to Simple in the mapping screen. Delete an attribute of the Object Type. Change the import identifier for an object type.	Delete an object type Change the names of Object Types Change the names of the Attributes Change the attribute types Forget what you changed manually. Because if it is overwritten with a version upgrade, you need to manually configure it back. (For example: AQL filter in the Import mapping of JSM Assets) Create a new object type with the same name. Object Type names need to be unique in one schema for the external import to work properly. Create an attribute with the same name. Attribute names need to be unique in one schema for the external import to work properly.

Our applications improve continuously over time. This requires changes in the schema. For that reason, the actions listed in the “Better not to” column can be overwritten with a schema version upgrade.

In summary, we recommend the following:

1. Keep a change log for all manual configurations performed, including their dates.

2. Before clicking the 'Build Data Model' button to upgrade a schema version, review the roadmap page to learn what changes will be made.

Roadmap

If the schema version updates fail, it is most likely because of the changes listed in the “Don’t” column above. For example, if the admin deletes the Divisions object type, this would break the reference from Users to Divisions. As a result, the schema update would fail with the following error:
- Error Type: dataValidationErrors
- Code: REFERENCED_OBJECT_TYPE_CHANGED
- Location: Users.Division