Considerations for Destiny Resource Manager's Mobile Device Management (MDM) integration:
Jamf Pro

Districts should consider some things when deciding to integrate Jamf Pro with Destiny Resource Manager. There are many options and nuances to the base configuration, which can make integrating complicated – especially when your devices are already in Resource Manager.

This information is not intended to be a comprehensive explanation of all features and possibilities. It gives a high-level overview of the functionality.

Contact your Follett technology sales representative to schedule a discussion of the process, and hear about our implementation services.

Capabilities

While you can use a data file of resource records and manually convert and import it into Resource Manager, there are two main benefits of MDM Integration:

  • Automatic loading of Jamf Pro data into Destiny: The MDM Integration feature is designed to let data automatically flow into Destiny, adding and updating records in Destiny based on changes in Jamf Pro. When a new device is provisioned, it can be added to Destiny automatically.
    Note: This functionality is only available if Jamf Pro data is organized in Smart Groups.
  • Updating Jamf Pro data based on changes in Destiny: Rules can be set up which can automatically change a device's state or group based on actions taken in Resource Manager. When a device is marked Lost in Resource Manager, it can be put into Lost Mode in Jamf Pro automatically.

Scope Limitations

The scope of the integration is limited to:

  • iOS devices: The integration is built to work with the Jamf Pro APIs that provide access to the iOS devices. It is not designed for working with MacOS or other technology in Jamf Pro.
  • One resource type: To keep the process as simple as possible, the integration is built to work with one resource type in Resource Manager. It is not designed to work with multiple types of devices organized in multiple resource types.

Requirements

There are certain data points that must be reviewed and considered before beginning integration:

  • Device Name: In Resource Manager, devices are organized as resources, each having a unique name within a specific resource type. The displayable name of the resource can be comprised of multiple fields on the resource record. The Jamf Pro model field is the common field that has the corresponding value. For the initial sync and for future additions, it is important for the name values to match. The integration offers a Transform function that can be used to connect existing values in Jamf Pro to existing values in Resource Manager.
  • Item Barcode: Because the item barcode is the field used for checking out and checking in items, it is a required field in the resource type definition. The Jamf Pro asset tag field is the common field used to store this data.
  • Destiny Site: One of the key benefits of Resource Manager is to let your district know where things physically reside in the district. This helps you save time and money by moving existing items from site to site, instead of buying additional items. The integration provides two means of linking Jamf Pro data to Destiny sites:
    • Static Groups: Using the static group field in Jamf Pro, you can specify a site value.
    • Smart Groups: Using Smart Groups, you can specify a location using the Building field.
  • Other: Each resource type can have its own configuration, including required fields. There may be additional fields required in the target resource type. This will be indicated on the field mapping screen. Whether or not a field is required can also be adjusted in the resource type definition.
  • Jamf Pro data to load into Destiny: You must be able to limit the data flow from Jamf Pro into Resource Manager. The process for selecting what to synchronize with Destiny is done by selecting a set of static/smart groups.

Available Fields

There are many fields available for mapping from Jamf Pro to Resource Manager through the MDM Integration functionality.

Integration Overview

Following are the basic steps to a successful integration:

  1. Create an account in Jamf Pro: Create the account that the MDM Integration system will use to authenticate into the MDM.
  2. Configure the connection info: Connect the MDM Integration to Jamf Pro.
  3. Test the account: Use the MDM Integration tests to verify all of the needed permissions are set up.
  4. Select the data to load: Choose what groups to synchronize with Resource Manager.
  5. Select the site mapping: Configure the static/smart groups to Destiny site relationships.
  6. Select the resource type to sync into: Choose the one resource type where the data will live.
  7. Configure the field-to-field mapping: Select the source fields Jamf Pro will route into the desired fields in Resource Manager, and set any additional options for each field.
  8. Run the reports, and resolve issues: Review the output of the evaluation and comparison reports to resolve syncing conflicts before loading the data.

    • All Jamf Pro device data for the selected groups: This report gives a full export of all data available for syncing into Destiny.
    • Jamf Pro device data evaluation: MDM Integration reviews the Jamf Pro data and reports problems relating to:
      • Required fields that are empty: Devices in this state will be skipped when loading into Destiny.
      • Duplicate values in fields that should be unique: Multiple devices with the same barcode or serial number will each process, causing confusion.
    • Jamf Pro to Destiny data comparison: MDM Integration compares the Jamf Pro data against data existing in Resource Manager and reports devices that are:
      • Site mismatches: According to the mapping, Jamf Pro says a device is in site A, while in Destiny it is currently in site B.
      • Name mismatches: This is a safety check to ensure device data in Jamf Pro and Resource Manager match by name. This report can help uncover additional needed setup, such as:
        • Model field value transformations: Using the Transform function to "find/replace" value strings.
        • Relaxed Matching rules: Using the option to match just on Barcode and ignoring the name matching safety check.
      • Not in Destiny: This is a "heads up" report to help identify devices in the selected groups that you don't actually want to sync to Resource Manager. This can be very helpful for cleaning up Jamf Pro before unwanted data is added into Resource Manager.
  9. Perform the initial Import & Sync Data operation: Import the first load, which will sync together the Jamf Pro and Resource Manager records for updates moving forward.

    See the Match Processing section.

    Note: If there is no device data in Resource Manager already, all the records will be created in this step.

  10. Configure the bidirectional rules: Configure changes that can be made in Jamf Pro based on the state changes in Resource Manager, and similarly from Jamf Pro to Resource Manager.
  11. Turn on Autosync: Enable the automatic flow of data from Jamf Pro to Resource Manager and Resource Manager to Jamf Pro.

    Note: Autosync is only available when using Smart Groups.

Match Processing

The following gives a summary of the logic used to match incoming data to Resource Manager, whether on the initial sync or subsequent updates – manual or autosync.

  • Resource Matching:
    • Displayable Name: In Resource Manager, up to four fields can be concatenated to make up the displayable name. When performing matching, the MDM Integration builds up the displayable name in the same manner.
      • If a resource by that name already exists, it is updated appropriately based on the settings.
      • If a resource does not exist, it is created using the incoming data.
  • Item Matching:
    • Global Unique Identifier (GUID): The first match routine is the most secure, looking for the GUID value from Jamf Pro in Resource Manager. If it is found, it is evident that the item was added through the MDM Integration or was previously synced and is the exact, right item to update.
    • Barcode/District ID: If the item is not found by GUID, then the integration looks for either the barcode or district ID value based on the configuration. This is beneficial for the initial Import and Sync Data routine, tying the two systems together. It is also how the system knows to add a new item to Resource Manager. If no match is found on GUID or Barcode/District ID, then the item is added.
      • Displayable Name verification: When a match is found, the system also performs a safety check to make sure it has found the right item under the right resource. If the item is found by GUID or by Barcode/District ID, under a different displayable name than the incoming value, the discrepancy is noted in the Audit Event logging and the item is skipped.
      • Relaxed: There is an option to match without checking the displayable name value and to only match on GUID/Barcode/District ID. This can be useful if the names in Resource Manager are unique to different needs in Resource Manager, but have a common/generic model value in Jamf Pro.