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.

...

• 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.

...

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.

...

• 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.

...