Single Source of Truth

Every organization has the desire to have a single source of truth.

In this article, we will explain the different options and the reasons why you could select one, the other, or both.

Proper Definition

The purpose of Pio Importer applications is exactly to enable organizations to build JSM Assets as a single source of truth. We have built applications that will import data from 15+ external systems.

On the other hand, while defining “JSM Assets is the single source of truth” is a correct statement, but defining “One object schema is the single source of truth.” is not correct and not our recommendation.

Our recommendation is keeping the data separately.

Your Reasons

1- Organizations commonly manage data from multiple systems, which have totally different ways of keeping the data. These systems have their own release cycles and change in time. Their APIs and Data Models improve continuously.

2- The data property details (object type attributes) of these systems are different. Each attribute may allow you to enable another use case. Losing the attributes of these systems would be limiting the flexibility and decrease the value that you would get from JSM.

3- Our applications also improve in time, including the enhancements in the data model of the source system. Aggregating all the object types into the same object schema increases the risk of conflicts of the future version updates. As a result, they may be out of the scope of our support services.

4- Every organization has very strict security policies, data protection, and data privacy guidelines which are especially essential. The IT industry accepts the least privileged access model as a general principle. JSM Assets has the access permission settings at the object schema level. Keeping schemas for multiple systems allow you to provide access to only the people who really need to view or edit the data. In case they are in the same object schema, they will be exposed to more people.

5- It is important to note that a user having read only access to an object schema can download the data to csv files. To be clear, a Jira user having access to an Object Schema with the Object Schema User role, which is a read-only permission, can download the full list of employees, including their personal details, to their personal laptops. And, unfortunately this activity is not recorded in the audit logs of JSM Assets and JSM. Risk and compliance teams generally mark this status as high risk and request Jira Admins to give minimum access to the employees. Sometimes adding one user requires approvals because of these risks.

6- Once the number of object types are more than 10, usability of JSM Assets user interface becomes harder. Even experienced users may get confused while switching between object types and attributes. This can easily cause mistakes and Assets doesn't have an undo button or rollback function. It may result creating the structure from scratch which means losing the relations between tickets and objects or object activity history.

7- There are no limitations in Assets Custom Fields or Automation rules to handle the data from 2 different object schemas. It is possible to use multiple Assets Custom Fields or lookupObjects components to interact with the schemas.

8- It is possible to create relationships between different Object Schemas in JSM Assets.

These are a few of the topics that you need to consider while you are building your Asset and Configuration Management practice on JSM Assets. All items listed above are lessons learned by experience.

Knowing that one of the most important data types is the Users, 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 (Entra ID) 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