This article explains two different methods to leverage the User related information that is stored in JSM Assets.

Option 1

One way to connect multiple object schemas is to keep adding a new Jira User attribute to the “Users” object type.

Facts about our importer applications:

• Most of our applications have an object type called Users/People etc to store the user related information.

• Every source you own (Entra ID, Intune, Jamf, Google Workspace, Okta, Snipe-IT, Torii, Datadog, Salesforce, Hubspot, Tempo, and Databases) has a different User definition, and the attributes may vary.

• They all have the email address information, which can be used to map the Jira User.

Facts about JSM:

• JSM has a great cloud automation feature that can execute API calls, and update objects that are stored in JSM Assets. This way it is possible to map the imported “Users” objects and the Jira Users (a.k.a. Jira Cloud - User Accounts).

Facts about JSM Assets:

• JSM Assets feature has nice and practical AQL functions. For example, currentReporter() or currentUser(). They can be used to filter issue scope for an Assets Custom Field.

  • "Jira User" = currentReporter()

  • "Owner"."Jira User" = currentReporter()

• Object Types can have an attribute type called “User” which stores the Jira User Account ID.

• Access permission settings for your data are on the Object Schema level of JSM Assets.

  • Any user having read-only or edit-level access to an object schema can download the list of objects to a CSV file. To make it clear: a user can download the list of employees including the personal information to their laptop. This is generally a red flag. Organizations' risk and compliance departments enforce the least privilege model to be applied in every IT system. In other words, they don’t like a large number of users accessing sensitive information.

  • This requires every data source to be stored in a separate object schema.

As a summary, our recommended configuration is shown in the diagram below. The benefits of this configuration are:

• Keeping data from each source separately ensures the correct permission settings and implementation of the least privilege model.

• Using the JSM Assets' out-of-the-box feature and mapping objects to Jira Users allows the use of simple and practical AQLs.

• Jira Cloud automation makes it possible to perform the mapping.

Solution for Option 1:

The following document contains a step-by-step guide explaining how to map Jira Users with an Object Type.

Mapping Azure AD Users with Jira Users and Jira Groups

Option 2

Using the full employee list as the connector is another preferred option.

Facts about our importer applications and the data transferred:

• Every organization stores employees' lists in its IDP (e.g., Entra ID, Okta, Google Workspace, etc.). Our applications simplify the import process from these systems into JSM Assets.

• The data transferred from the End-User Device platforms (e.g., Intune, Jamf, Snipe-IT, etc.) are only a part of the total list of employees.

• Organizations may have one or multiple of these sources.

• Generally, end user device platforms don’t share the same users. For example, an employee may have a windows device or a mac device but not both at the same time. It is very rare. In that case, the best is mapping them to the data coming from IDP.

Solution for Option 2:

The following document contains a step-by-step guide explaining how to connect multiple object schemas.

Connecting Multiple Object Schemas